Turtles All the Way Down

The time has come for Rubyists in general and Rails in particular to embrace Ruby’s Lisp heritage and ditch YAML as a configuration default for database. Code is Data/Data is Code. There are a host of reasons why Ruby is great for configuration and only a few in favor of YAML. Let’s look at why we use YAML in the Ruby community:

• You don’t have to quote Strings sometimes
• It is better than XML.
• Rails does it in the database configuration.

Point one is a bit of a red herring, but the idea behind it is that YAML is sparse and a great deal more human readable than alternatives. This is true and tying to point two, I really get how that was a big win in 2005. I’ve done a lot of Java development and I think there is no better quote than:

Java is a DSL to transform big XML documents into long exception stack traces. —Scott Bellware

XML, like Java, is human readable, just not easily human readable in any degree of length or complexity. XML and Java are a bit more optimized for readability by the computer. YAML, like Ruby, goes the other direction and leans towards optimization of readability for the programmer. Their APIs are both easier for humans to plug into and I believe that is why they were inspired choices for the Rails framework eight years ago. But it is not 2005 and if comparable configurations in a Ruby hash structure are too confusing, you have another problem that YAML does not solve.

Let’s compare the basic example from the Ruby on Rails Guide: Yaml:

development:
  adapter: postgresql
  database: blog_development
  pool: 5
  username: blog
  password:

Ruby:

{ development:
  { adapter: "postgresql",
    database: "blog_development",
    pool: 5,
    username: "blog",
    password: "password"
}}

I contend the difference is minimal, and the little bit of punctuation is made up for by all of the benefits of using pure Ruby.

It is the Simplest Thing that Can Work.

The YAML library is an entire library to convert a YAML file into a ruby data structure. The complexity is hidden from you, but why embrace it? I get that it is built into Rails, but then other folks look into how to expand the use of YAML crutch because it is the path of least resistance in one area, so the natural impulse is to use the same hammer everywhere else. How about we just drop the need for that hammer?

Built in Rich Data Structures.

Turing Complete without the Need to Wrap in ERB.

In order to add any dynamic nature to YAML, you need to wrap it in ERB to then use Ruby. Now we’re up to two wrapper libraries to convert data to a ruby data structure and diminishing the differentiator of YAML’s readability.

Here’s a bit of a contrived comparison:

YAML:

development:
  adapter: postgresql
  database: <%= "blog_development" if `echo $HOSTNAME`=="dev-machine" %>
  pool: 5
  username: blog
  password:

vs Ruby:

{ development:
  { adapter: "postgresql",
    database: ("blog_development" if `echo $HOSTNAME`=="dev-machine"),
    pool: 5,
    username: "blog",
    password: "password"
}}

Rails is Already Doing 95% of its Configuration in Ruby.

All of those Ruby files in the config directory… Go all the way.

Java Libraries Have Started to Figure It Out.

Do we really need the Java world to show us the power of configuring applications with a dynamically-typed, interpreted language?

Martin Fowler Said So.

Come on Rails, I know it is Omakase and all about a refined palette, but YAML for configs is very California Roll. With the improved hash syntax of Ruby 1.9 there is very little reason to use YAML for configuration file these days. Rubyists in general and the Rails project in particular should move in the direction of configuring Ruby applications with Ruby.

Let me know your thoughts…

—Mike McDermott (@planetmcd)