The 5 levels of configuration languages

Summary

Code is data and data is code. Years ago, I had a brief affair with Lisp and there I picked up this meme. Today, I believe there are also benefits in separating code and data. Glimpses of this debate come up whenever people discuss the syntax for yet another configuration schema. There are 5 levels of power for configuration languages. If you design a new schema, be aware of all of them. Level 1: String in a File The file system is a key-value store. The Linux kernel does it with procfs and sysfs. Example from my shell: $ cat /proc/sys/kernel/arch x86_64 $ cat /proc/sys/kernel/sched_energy_aware 1 I could write 0 to the second one to change the kernel behavior. This certainly is the simplest format, yet it works. Level 2: A List For a little bit more expressive power, you can treat the file contents as a list. Maybe one per line. Maybe a key-plus-value per line. Maybe with sections like an INI file. Example file contents: [database] server = 192.0.2.62 port = 143 file = "payroll.dat" This is already complex enough that not everything is intuitive. What happens if you duplicate a key? Can you do multiline strings? The defining constraint is that you cannot have a list of lists. That would be the next level. However, think twice before going there because with a little pre- and postfixing names, you can do a lot here. Level 3: Nested Data Structures This is probably the most popular level, where we find JSON, YAML, XML, TOML, etc. Example file contents: { "database": { "host": "localhost", "port": 1234, "auth": { "user": "elon", "password": "mars2023" } } } It is fascinating how much people can discuss about the pros and cons of the alternatives on this level even though they are more or less the same. I actually like XML. It isn't "cool" like YAML anymore, but it has better tooling support (e.g. schema checking) and doesn't try to be too clever. Just try to stay away from namespaces and don't be afraid of using attributes. In practice, many later encounter the limita...