Configuration File Demise

I'm not a big fan of predicting the future; therefore, this entry is more of a question than a statement. And, the question is, do dynamic languages mark the end of developer written configuration files?

Let's start with what's out of the scope of this conversation. Configuration files written or maintained by non-developers will not only live on but hopefully the maturity of Domain Specific Language development will deliver higher value configuration files.

This should leave us with the narrowly focused discussion of developer written and maintained configuration files.

Currently, most developer-centric configuration files are written in XML (though YAML has quickly caught on among those who dislike angle brackets). These configuration files often allow you to transform strings into objects or graphs of objects. Clearly, the abstraction required to make this work can be custom developed or you can make use of an existing library such as YAML.rb or the .net configuration classes. However, these configuration frameworks increase overall application complexity by adding a dependency and requiring knowledge of the framework.

One notable benefit of using a configuration file is the ability to change application behavior without the need to recompile the application. However, dynamic languages do not require compilation. Therefore, you can change the behavior of the application simply by changing the class and deploying the changes. For example, in ruby, a file will be loaded repeatedly if you use load instead of require. For performance reasons require is generally used; however, if you had a file that you planned on changing without restarting the application you could use load instead.

Another notable benefit of configuration files is the reduction in noise within a configuration file. However, in dynamic languages, such as ruby, it is possible to use class methods and meta-programming to eliminate the unnecessary repetitive code. For example, Ruby on Rails uses a database.yml file to specify database connection information. However, you could just as easily use a class such as

class Development < DatabaseInformation
  host "localhost"
  username "jay"
  password "password"
end

So, it appears it is possible to live in a world without developer-centric configuration files; however, is there any benefit to this shift? I believe there is. As I previously stated, each configuration framework requires adding a dependency and understanding of usage. By removing this dependency I can more quickly understand how the entire application works and I can focus on solving the problem at hand.

An (admittedly simple, yet real world) example is the configuration information for the Ruby Continuous Integration application my team recently wrote. The application needed to know the path to the directory where revision and build information was located. This information could be stored in a YAML file, but that would require using the YAML library to load the information. A much simpler solution was to simply create a class that stored the information:

class OutputDir
  def self.builds
    "/builds"
  end

  def self.revisions
    "/revisions"
  end
end

This implementation (obviously) allowed me to use OutputDir.builds when I needed to specify the builds directory. It is also very obvious exactly what is going on to any person who looks at this file. To me, this was the simplest thing that could possibly work.

The gain in simplicity is obvious; therefore, the real question is, are there any benefits that configuration files provide that simple classes cannot?