5 ms·

If JSON just originally had comments there wouldn't be such a proliferation of redundant configuration language, since JSON serves perfectly well 99% of cases.

m000 3y ago
Comments, and allowing trailing commas after the last element of an array/dictionary.
- enriquto 3y ago
  And standard floating point numbers.
  - svieira 3y ago
    Multiple bases would be better than standardizing on how to represent floating point numbers, since floating point still results in errors with unrepresentable values (e. g. 1/3 in base 10).
    - harles 3y ago
      Base 10 is sufficient. Any base 2 number can be represented exactly in base 10. If you need rational numbers, you need something other than floating point.
- jerf 3y ago
  Comments, trailing commas, and multiline strings. Comments, trailing commas, multiline strings, and a real date type. Comments, trailing commas, multiline strings, a real date type, and dropping the quotes on keys. Comments, trailing commas, ... JSON really isn't just the "simple tweak" away from being the perfect config language it is often presented as. There's this fun sort of error that only a group of people can make, where someone can stand up and make a statement like "JSON just needs a couple of tweaks to be the perfect config format!" and everyone can individually nod in agreement, and the group thinks it is in agreement. But it turns out every individual actually had a completely different interpretation of the statement and they don't agree at all. When you get a group of developers together to be clear about the changes to JSON you will discover not everybody has the same tweaks in mind. (& I wrote this before seeing the sibling comment from enriquto who gives another thing necessary for perfection. I don't even 100% know what enriquto means by "standard" floating point numbers versus what is already in the spec, but I bet it's another thing that multiple people could nod in agreement to but in fact mean something quite different about if you nail them down to the spec level!)
  - BurningFrog 3y ago
    "Perfect config language" is too high a standard. JSON could be much better, and good enough for far more purposes, with the top 3 tweaks there.
  - lolinder 3y ago
    To be fair to JSON, this is why there are no config formats that are good enough for everyone. They either try to meet all of these requirements and people complain they're too complex, or they choose a subset of the requirements and only satisfy a subset of people.
    - jerf 3y ago
      Strong agree. I think it's not entirely unlike programming languages. If I sit down and write out all the features I want from a programming language, I can't have it. They straight-up contradict each other. As a simple example, I want simplicity and a rich type system. Nope. Not gonna happen. Intrinsically at odds with each other. And there are many other such places, more subtle than that but no less real. Config has the same thing going on. I've made my peace with just doing whatever's convenient in the moment and not stressing about it. It certainly isn't worth bringing in a new syntax my local team has never heard about because it's just the perfect little config syntax. It's very hard for any config syntax to be better enough than what came before to justify adding another tech to the stack.
    - eviks 3y ago
      It's not fair to JSON, and to see why you just need to add some quantities to the quality of "nothing is great for everyone". Like, a huge % of users would need comments, so that's a huge downside of JSON, and it doesn't matter that there is no perfect non-complex config format with floats (or whatever) since that would be too complicated
  - scythe 3y ago
    I don't really think that any of those are as important as comments, though. Comments are indispensable for a self-documenting config file. Trailing commas and so forth are merely convenient. JSON with comments wouldn't be perfect, but it would be unacceptable a lot less often.
deleted 3y ago
[deleted]
dorfsmay 3y ago
https://json5.org/ https://json5.org/
carapace 3y ago
I was just thinking this morning how JSON is a symptom of people not learning formal grammar et. al. as part of their education and training. Maybe it's just because I cut my teeth on Wirth languages, but JSON seems like net negative productivity.
- bonzini 3y ago
  JSON was designed as a wire format, not as a configuration file. The original idea was to validate it with a regex to exclude malicious input and then eval() it. That explain why it's such a small subset. TOML on the other hand is also a clear indication that Tom did not like using (or hadn't learned about) a formal grammar.
  - carapace 3y ago
    JSON wasn't designed? It's just the literal notation from JS extracted, no? And I don't thing you can validate JS with a regex? (Have I forgotten that much of formal language theory?)
sophacles 3y ago
The proliferation of configuration languages is far older than JSON. There's just a couple inherent problems with the notion of a universal configuration language... First not all software has the same type of configuration requirements. I don't mean different schemas, I mean some measure of "configurablity". You have things like nginx or varnish that are configurable enough that configs are almost (or actually) programs. You also have programs where you need to store a few KVs that will be inserted into strings at some point and that's it. That wide range of "amount of possible configuration" is hard to capture easily in a single configuration language. Next you have a wide range "flatness" - that is if the configuration needs to be a list of kvs (optionally w/ sections) or if you need a tree or graph shape, or something weird. Finally there's the whole preference and "style" thing. Writing a config language has an appeal to it - it's a fairly straight-forward thing to do (at least seemingly, until you hit the edge cases), and it's infinitely bikeshedable. In a similar vein, it seems to devolve into this sort of thing quite often: https://xkcd.com/927/ https://xkcd.com/927/ This is one of those situations where it's nice to be "old" - I like that I only have to know a handful of config formats these days, rather than keeping track of each program's bespoke config format.

m000 3y ago

Comments, and allowing trailing commas after the last element of an array/dictionary.

enriquto 3y ago
And standard floating point numbers.
- svieira 3y ago
  Multiple bases would be better than standardizing on how to represent floating point numbers, since floating point still results in errors with unrepresentable values (e. g. 1/3 in base 10).
  - harles 3y ago
    Base 10 is sufficient. Any base 2 number can be represented exactly in base 10. If you need rational numbers, you need something other than floating point.
jerf 3y ago
Comments, trailing commas, and multiline strings. Comments, trailing commas, multiline strings, and a real date type. Comments, trailing commas, multiline strings, a real date type, and dropping the quotes on keys. Comments, trailing commas, ... JSON really isn't just the "simple tweak" away from being the perfect config language it is often presented as. There's this fun sort of error that only a group of people can make, where someone can stand up and make a statement like "JSON just needs a couple of tweaks to be the perfect config format!" and everyone can individually nod in agreement, and the group thinks it is in agreement. But it turns out every individual actually had a completely different interpretation of the statement and they don't agree at all. When you get a group of developers together to be clear about the changes to JSON you will discover not everybody has the same tweaks in mind. (& I wrote this before seeing the sibling comment from enriquto who gives another thing necessary for perfection. I don't even 100% know what enriquto means by "standard" floating point numbers versus what is already in the spec, but I bet it's another thing that multiple people could nod in agreement to but in fact mean something quite different about if you nail them down to the spec level!)
- BurningFrog 3y ago
  "Perfect config language" is too high a standard. JSON could be much better, and good enough for far more purposes, with the top 3 tweaks there.
- lolinder 3y ago
  To be fair to JSON, this is why there are no config formats that are good enough for everyone. They either try to meet all of these requirements and people complain they're too complex, or they choose a subset of the requirements and only satisfy a subset of people.
  - jerf 3y ago
    Strong agree. I think it's not entirely unlike programming languages. If I sit down and write out all the features I want from a programming language, I can't have it. They straight-up contradict each other. As a simple example, I want simplicity and a rich type system. Nope. Not gonna happen. Intrinsically at odds with each other. And there are many other such places, more subtle than that but no less real. Config has the same thing going on. I've made my peace with just doing whatever's convenient in the moment and not stressing about it. It certainly isn't worth bringing in a new syntax my local team has never heard about because it's just the perfect little config syntax. It's very hard for any config syntax to be better enough than what came before to justify adding another tech to the stack.
  - eviks 3y ago
    It's not fair to JSON, and to see why you just need to add some quantities to the quality of "nothing is great for everyone". Like, a huge % of users would need comments, so that's a huge downside of JSON, and it doesn't matter that there is no perfect non-complex config format with floats (or whatever) since that would be too complicated
- scythe 3y ago
  I don't really think that any of those are as important as comments, though. Comments are indispensable for a self-documenting config file. Trailing commas and so forth are merely convenient. JSON with comments wouldn't be perfect, but it would be unacceptable a lot less often.

deleted 3y ago

[deleted]

dorfsmay 3y ago

https://json5.org/ https://json5.org/

carapace 3y ago

I was just thinking this morning how JSON is a symptom of people not learning formal grammar et. al. as part of their education and training. Maybe it's just because I cut my teeth on Wirth languages, but JSON seems like net negative productivity.

bonzini 3y ago
JSON was designed as a wire format, not as a configuration file. The original idea was to validate it with a regex to exclude malicious input and then eval() it. That explain why it's such a small subset. TOML on the other hand is also a clear indication that Tom did not like using (or hadn't learned about) a formal grammar.
- carapace 3y ago
  JSON wasn't designed? It's just the literal notation from JS extracted, no? And I don't thing you can validate JS with a regex? (Have I forgotten that much of formal language theory?)

sophacles 3y ago

The proliferation of configuration languages is far older than JSON. There's just a couple inherent problems with the notion of a universal configuration language... First not all software has the same type of configuration requirements. I don't mean different schemas, I mean some measure of "configurablity". You have things like nginx or varnish that are configurable enough that configs are almost (or actually) programs. You also have programs where you need to store a few KVs that will be inserted into strings at some point and that's it. That wide range of "amount of possible configuration" is hard to capture easily in a single configuration language. Next you have a wide range "flatness" - that is if the configuration needs to be a list of kvs (optionally w/ sections) or if you need a tree or graph shape, or something weird. Finally there's the whole preference and "style" thing. Writing a config language has an appeal to it - it's a fairly straight-forward thing to do (at least seemingly, until you hit the edge cases), and it's infinitely bikeshedable. In a similar vein, it seems to devolve into this sort of thing quite often: https://xkcd.com/927/ https://xkcd.com/927/ This is one of those situations where it's nice to be "old" - I like that I only have to know a handful of config formats these days, rather than keeping track of each program's bespoke config format.