5 ms·

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

by mikl 7y ago

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.

dbcurtis 7y ago
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.
- ptest1 7y ago
  TOML is extremely verbose for lists. It’s ridiculous. Sure it had less features than YAML but it also looks considerably worse in all the common use cases. Looks like INI
  - dbcurtis 7y ago
    Yeah, I was fighting the list problem. And not able to mix numeric and string data in a list just made the whole thing unwieldy and frustrated me. I’ve used JSON for configs, which is not great, but at least readable. The biggest problem is lack of comments, but I added a quick hack to ignore any dictionary key starting with an octothorpe. Not ideal, but is actually handy because it makes it easy to comment out keys temporarily as well as add arbitrary commentary. Also, the Python standard library JSON parser is very flexible and yields precise exceptions. I was able to turn those parsing exceptions into meaningful error messages with precise line and column numbers. Which came as a bit of a shock to some of my users, because a different tool written before my time but used by the same people had exactly one error message for mispelled YAML: segfault.
ptest1 7y ago
Schemas, interesting. I wonder where we’ve seen that before..
- leetrout 7y ago
  We could have a URI that gives you a schema and some tools to generate a skeleton for that schema for you. Then you could put a header in your request for what you want to do and send that payload. Like a simple configuration access and management (SCAM) protocol. Yes, yes I think we’re on to something here.
lonelappde 7y ago
New standards: https://xkcd.com/927/ https://xkcd.com/927/
- cwp 7y ago
  The problem is not that there are too many configuration languages. The problem is that none of them are any good. The way to solve that is to keep trying new ones until we find one that is good.
  - leg100 7y ago
    Or the premise is a false one, that a configuration language is not the right approach. And everytime yet another such language falls flat only serves to reinforce this very point.
    - krapp 7y ago
      Configuration languages succeed and work just fine most of the time, despite their inadequacies and quirks, but no one ever complains about them when they work. Go ahead and write your configuration as a fully Turing complete sub-application in whatever language you like. It will do everything you could possibly want, and in a few years it'll grow so complex and hairy that it will need its own fully Turing complete sub-application to configure it, lather, rinse, repeat. If you're really clever, every configuration layer will be written in a separate language with its own dependency tree, test framework, and toolchain. Personally, I prefer not having to recompile just to change some variables and settings. I'm fine with INI or JSON (although I prefer Lua tables) when they're appropriate. The problem is not that configuration languages are a bad idea, the problem is interminable Turing creep and developers wanting every aspect of their applications to be as flexible and powerful as possible. The premise of having a separate config language is fine - somewhere, somehow, inevitably, you're going to need a read-only data store for globals and references to system settings. You can hardcode all of those variables in your application or put them elsewhere.
      - leg100 7y ago
networkimprov 7y ago
If it doesn't at least "compile" to JSON, how are we to load it into arbitrary environments?
- zellyn 7y ago
  It does
arc33 7y ago
> XML is awful 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.
- willtim 7y ago
  XML and especially XML schema are hugely complex and almost laughably difficult to bind to any mainstream programming language. It took Java over a decade to produce a binding that could (perhaps) handle an arbitrary schema. Types boil down to sums and products, I'm not convinced the designers of XML/XSD understood this. XML has so many overlapping concepts: elements, attributes, enumerations, choices, unions, sequences, lists, element/attribute groups, substitution groups, facets, simple types, complex types etc etc IMHO it's ad-hoc and ugly; we deserve better.
  - arc33 7y ago
    > XML and especially XML schema are hugely complex and almost laughably difficult to bind I'm not very well versed in XML schema but if it were needlessly complex, it's probably not a good idea to throw baby out with the bathwater? XML seems more type safe, easier to fold larger XML documents than JSON or YAML and it seems safer to edit. Looks like, we're now reinventing all the XML advantages with a new config language, one at a time. First, JSON came because it looks simple at first sight, but looks hard as soon as the JSON is huge, no different or better than XML, in fact, probably worse. Then YAML appeared because, now it even allows you to add comments to config files, but it's a nightmare to edit, one wrong indentation and the YAML will blow up at runtime. And looks like, we're now coming up with other languages to add in the missing functionality that XML already provided.
- mikl 7y ago
  My main complaint with XML is that it’s far too complex for most use cases (like config files), and thus requires an unhealthy amount of tooling to work with. I can’t just load the file and run it through a parser and get an easily accessible object structure back, I’ll need to navigate the document with DOM or XPath. JSON with comments (aka JSONC) is in my opinion the best format in wide use today. It has structure and types, but not too many, and not a lot of magic, like YAML has, but for the most complex cases, JSON(C) falls short with its lack of extensibility and inheritance.
blondin 7y ago
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...

by mikl 7y ago

dbcurtis 7y ago

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.

ptest1 7y ago
TOML is extremely verbose for lists. It’s ridiculous. Sure it had less features than YAML but it also looks considerably worse in all the common use cases. Looks like INI
- dbcurtis 7y ago
  Yeah, I was fighting the list problem. And not able to mix numeric and string data in a list just made the whole thing unwieldy and frustrated me. I’ve used JSON for configs, which is not great, but at least readable. The biggest problem is lack of comments, but I added a quick hack to ignore any dictionary key starting with an octothorpe. Not ideal, but is actually handy because it makes it easy to comment out keys temporarily as well as add arbitrary commentary. Also, the Python standard library JSON parser is very flexible and yields precise exceptions. I was able to turn those parsing exceptions into meaningful error messages with precise line and column numbers. Which came as a bit of a shock to some of my users, because a different tool written before my time but used by the same people had exactly one error message for mispelled YAML: segfault.

ptest1 7y ago

Schemas, interesting. I wonder where we’ve seen that before..

leetrout 7y ago
We could have a URI that gives you a schema and some tools to generate a skeleton for that schema for you. Then you could put a header in your request for what you want to do and send that payload. Like a simple configuration access and management (SCAM) protocol. Yes, yes I think we’re on to something here.

lonelappde 7y ago

New standards: https://xkcd.com/927/ https://xkcd.com/927/

cwp 7y ago
The problem is not that there are too many configuration languages. The problem is that none of them are any good. The way to solve that is to keep trying new ones until we find one that is good.
- leg100 7y ago
  Or the premise is a false one, that a configuration language is not the right approach. And everytime yet another such language falls flat only serves to reinforce this very point.
  - krapp 7y ago
    Configuration languages succeed and work just fine most of the time, despite their inadequacies and quirks, but no one ever complains about them when they work. Go ahead and write your configuration as a fully Turing complete sub-application in whatever language you like. It will do everything you could possibly want, and in a few years it'll grow so complex and hairy that it will need its own fully Turing complete sub-application to configure it, lather, rinse, repeat. If you're really clever, every configuration layer will be written in a separate language with its own dependency tree, test framework, and toolchain. Personally, I prefer not having to recompile just to change some variables and settings. I'm fine with INI or JSON (although I prefer Lua tables) when they're appropriate. The problem is not that configuration languages are a bad idea, the problem is interminable Turing creep and developers wanting every aspect of their applications to be as flexible and powerful as possible. The premise of having a separate config language is fine - somewhere, somehow, inevitably, you're going to need a read-only data store for globals and references to system settings. You can hardcode all of those variables in your application or put them elsewhere.
    - leg100 7y ago

networkimprov 7y ago

If it doesn't at least "compile" to JSON, how are we to load it into arbitrary environments?

zellyn 7y ago
It does

arc33 7y ago

> XML is awful 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.

willtim 7y ago
XML and especially XML schema are hugely complex and almost laughably difficult to bind to any mainstream programming language. It took Java over a decade to produce a binding that could (perhaps) handle an arbitrary schema. Types boil down to sums and products, I'm not convinced the designers of XML/XSD understood this. XML has so many overlapping concepts: elements, attributes, enumerations, choices, unions, sequences, lists, element/attribute groups, substitution groups, facets, simple types, complex types etc etc IMHO it's ad-hoc and ugly; we deserve better.
- arc33 7y ago
  > XML and especially XML schema are hugely complex and almost laughably difficult to bind I'm not very well versed in XML schema but if it were needlessly complex, it's probably not a good idea to throw baby out with the bathwater? XML seems more type safe, easier to fold larger XML documents than JSON or YAML and it seems safer to edit. Looks like, we're now reinventing all the XML advantages with a new config language, one at a time. First, JSON came because it looks simple at first sight, but looks hard as soon as the JSON is huge, no different or better than XML, in fact, probably worse. Then YAML appeared because, now it even allows you to add comments to config files, but it's a nightmare to edit, one wrong indentation and the YAML will blow up at runtime. And looks like, we're now coming up with other languages to add in the missing functionality that XML already provided.
mikl 7y ago
My main complaint with XML is that it’s far too complex for most use cases (like config files), and thus requires an unhealthy amount of tooling to work with. I can’t just load the file and run it through a parser and get an easily accessible object structure back, I’ll need to navigate the document with DOM or XPath. JSON with comments (aka JSONC) is in my opinion the best format in wide use today. It has structure and types, but not too many, and not a lot of magic, like YAML has, but for the most complex cases, JSON(C) falls short with its lack of extensibility and inheritance.

blondin 7y ago

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...