4 ms·

I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human u

I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human use cases. YAML works well for human-to-machine (JSON could fill this use case as well if it would support comments and multi line strings). I don’t use TOML much, and good riddance to XML.

ChrisSD 7y ago
TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.
- weberc2 7y ago
  I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)
  - yellowapple 7y ago
    What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments). That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions. ¹: https://man.openbsd.org/pf.conf https://man.openbsd.org/pf.conf ²: https://man.openbsd.org/smtpd.conf https://man.openbsd.org/smtpd.conf ³: https://man.openbsd.org/relayd.conf.5 https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5 https://man.openbsd.org/httpd.conf.5 ⁴: https://otpcl.github.io https://otpcl.github.io
    - weberc2 7y ago
      I'm not coming from INI files. :) I actually always felt they did a poor job of representing anything more than key value pairs and they weren't standardized, so I always managed to avoid learning the grammar(s). I'm sure if I put much effort into it, I could figure out TOML, but I don't want to ask my users to figure out yet another configuration language. If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like. > That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. I'm not really familiar with this. I'll have to read up.
  - com2kid 7y ago
    TOML is what I'd naturally write as notes if I wanted to document how something is working. YAML is all sorts of strange. JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!
TravHatesMe 7y ago
"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job. For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.
- BubRoss 7y ago
  Years of experience > "the article" JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.
  - TravHatesMe 7y ago
    Your opinion != Everyone's opinion Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.
    - BubRoss 7y ago
      I didn't say any of that. JSON is a tree structure, that isn't an opinion.
      - TravHatesMe 7y ago
        My bad, I think I was responding to another comment.
- dec0dedab0de 7y ago
  Using child nodes to declare properties of an object is the main reason I dislike XML. Because some people use children, and some use attributes, and some use both. Granted, that isn't XMLs fault, but every time I to have get XML data into a usable format it feels like a struggle.
- weberc2 7y ago

ChrisSD 7y ago

TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.

weberc2 7y ago
I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)
- yellowapple 7y ago
  What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments). That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions. ¹: https://man.openbsd.org/pf.conf https://man.openbsd.org/pf.conf ²: https://man.openbsd.org/smtpd.conf https://man.openbsd.org/smtpd.conf ³: https://man.openbsd.org/relayd.conf.5 https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5 https://man.openbsd.org/httpd.conf.5 ⁴: https://otpcl.github.io https://otpcl.github.io
  - weberc2 7y ago
    I'm not coming from INI files. :) I actually always felt they did a poor job of representing anything more than key value pairs and they weren't standardized, so I always managed to avoid learning the grammar(s). I'm sure if I put much effort into it, I could figure out TOML, but I don't want to ask my users to figure out yet another configuration language. If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like. > That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. I'm not really familiar with this. I'll have to read up.
- com2kid 7y ago
  TOML is what I'd naturally write as notes if I wanted to document how something is working. YAML is all sorts of strange. JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!

TravHatesMe 7y ago

"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job. For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.

BubRoss 7y ago
Years of experience > "the article" JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.
- TravHatesMe 7y ago
  Your opinion != Everyone's opinion Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.
  - BubRoss 7y ago
    I didn't say any of that. JSON is a tree structure, that isn't an opinion.
    - TravHatesMe 7y ago
      My bad, I think I was responding to another comment.
dec0dedab0de 7y ago
Using child nodes to declare properties of an object is the main reason I dislike XML. Because some people use children, and some use attributes, and some use both. Granted, that isn't XMLs fault, but every time I to have get XML data into a usable format it feels like a struggle.
weberc2 7y ago