I realize this was meant to be sarcastic. However, I whole-heartedly and unironically agree. For writing small bits of configuration, just about any language will be fine. For large amounts of configuration, as is required for... oh, I dunno, let's say deploying software in the cloud, all the commonly used languages are a disaster.
Data serialization languages (like JSON, INI, XML, etc) lack the power to describe large configurations. There's no way to define an abstraction and then use it in multiple places. There's no way to constrain what is considered correct. You end up with tens of thousands of lines of very, very repetitive structures that are very fragile and hard to change.
General purpose languages are also bad for writing configurations. Yes, they're very powerful. That's not a feature when it comes to configuration. If you have a program that emits a configuration, the only thing you can do with it is run it, then inspect the resulting configuration. You can't inspect or transform the program at the level of the configuration semantics. You can't ensure that the configuration will have specific properties. You can't even ensure that the program will, in fact, emit a configuration.
So yeah, we need new configuration languages that lie in between data serialization languages and general purpose computing languages. We're starting to see them. HCL is awful, but it was an attempt at solving this problem and a move in the right direction. Jsonnet is maybe better better? I dunno, I've never tried it. Dhal is interesting, though difficult for non-Haskellers to approach. CUE is also interesting. Bravo!
We have all we need. If you want a full featured language, use that. Beyond that, we have JSON, YAML, INI and more. If you want something more complicated you can create your own DSL for your app.
We do indeed. XML is awful, YAML is a clusterfuck, JSON is often insufficient, and so is INI. TOML looks promising, but might not make it out of its niche.
If Cue is basically a better YAML with built-in schemas, that sounds pretty good.
I was hoping to like TOML, but my first experiments using a Python package for parsing it were disappointing. I found the syntax cranky, and the Python package I was using did a terrible job at providing diagnostics — very poor exception propagation.
And that seemed to be the most mature TOML parser that I could find for Python, so I decided TOML isn’t likely in my future.
I never really understood this. This seems to be an oft repeated truism from mid 2000s with little backing it up.
The only awesome thing that JSON did, was lose type information as well. In fact, the only thing that I can see that JSON brought to the table was easier editing by those who didn't have IDEs, at the expense of losing type information.
can you back what you are saying? i personally think we don't. most continuous integration pipelines need static configuration files, not languages. to be honest, i have no idea where this language fits in a software development process...
cwp|6 years ago
Data serialization languages (like JSON, INI, XML, etc) lack the power to describe large configurations. There's no way to define an abstraction and then use it in multiple places. There's no way to constrain what is considered correct. You end up with tens of thousands of lines of very, very repetitive structures that are very fragile and hard to change.
General purpose languages are also bad for writing configurations. Yes, they're very powerful. That's not a feature when it comes to configuration. If you have a program that emits a configuration, the only thing you can do with it is run it, then inspect the resulting configuration. You can't inspect or transform the program at the level of the configuration semantics. You can't ensure that the configuration will have specific properties. You can't even ensure that the program will, in fact, emit a configuration.
So yeah, we need new configuration languages that lie in between data serialization languages and general purpose computing languages. We're starting to see them. HCL is awful, but it was an attempt at solving this problem and a move in the right direction. Jsonnet is maybe better better? I dunno, I've never tried it. Dhal is interesting, though difficult for non-Haskellers to approach. CUE is also interesting. Bravo!
ptest1|6 years ago
We have all we need. If you want a full featured language, use that. Beyond that, we have JSON, YAML, INI and more. If you want something more complicated you can create your own DSL for your app.
If you want schemas and validation, use XML!
mikl|6 years ago
If Cue is basically a better YAML with built-in schemas, that sounds pretty good.
dbcurtis|6 years ago
And that seemed to be the most mature TOML parser that I could find for Python, so I decided TOML isn’t likely in my future.
arc33|6 years ago
I never really understood this. This seems to be an oft repeated truism from mid 2000s with little backing it up.
The only awesome thing that JSON did, was lose type information as well. In fact, the only thing that I can see that JSON brought to the table was easier editing by those who didn't have IDEs, at the expense of losing type information.
ptest1|6 years ago
blondin|6 years ago
networkimprov|6 years ago
lonelappde|6 years ago
sdinsn|6 years ago