I've used YAML for years, and yeah, there's a lot of warts, but I love it for small(ish) manually edited configuration files.
I generally keep it simple and it works.
YAML: probably not so great after all (2017)
381–390 of 412 posts
Re: YAML: probably not so great after all (2017)
#382Earlier quoted context omitted.
Most parsers will not support JSON5.
More like browsers can de-serialize JSON5 natively. writing a JSON5 parser is not difficult. It's just not part of most std libs in most languages, but I would argue that most std libs don't parse YAML either. JSON5 is a good compromise.
Neither Chrome nor Firefox's JSON.parse accept JSON5. I'm not sure what browser API you mean.
For example,
JSON.parse(`{"foo":"bar",}`)
Re: YAML: probably not so great after all (2017)
#383Earlier quoted context omitted.
Have you considered Lua tables? The syntax resembles JSON, but simpler, and keys don't need to be quoted. Trailing commas are allowed, and so are multiline strings.
I didn't have. But how do you parse it without Lua? Is a parser library available for mainstream languages?
> But how do you parse it without Lua?
You wouldn't, but the language is lightweight enough (according to Wikipedia, the interpreter is ~180kb compiled) that including it as a dependency probably won't matter. It's less overhead than an interpreter for JSON or YAML at least.
>Is a parser library available for mainstream languages?
It's used commonly in game development so yes for C and C++, and the site[0] mentions "Java, C#, Smalltalk, Fortran, Ada, Erlang, and even in other scripting languages, such as Perl and Ruby" as well.
Re: YAML: probably not so great after all (2017)
#384A couple thoughts. If your configuration file is so long it's unreadable in YAML, then maybe you need to break it up into more than one file? I can't imagine any syntax would be easy to read once you reach more than 100 or so lines. Do any configuration file languages support type hinting? Adding (int) in front of a YAML key would be easy enough to read, and would keep some of the confusion at bay.
YAML tags work this way. E.g., 2002-04-28 is a date (because it looks like one) but !!str 2002-04-28 is a string.
I had never heard of tags before. Thanks!
So, would this work?
ports:
https:
enabled: yes
!!int port: 443
Re: YAML: probably not so great after all (2017)
#385Earlier quoted context omitted.
I didn't have. But how do you parse it without Lua? Is a parser library available for mainstream languages?
> But how do you parse it without Lua? You wouldn't, but the language is lightweight enough (according to Wikipedia, the interpreter is ~180kb compiled) that including it as a dependency probably won't matter. It's less overhead than an interpreter for JSON or YAML at least. >Is a parser library available for mainstream languages? It's used commonly in game development so yes for C and C++, and the site[0] mentions "…
I know Lua and I use it sometimes (for example in Redis). But I don't want to include a full Lua interpreter in my program just to parse a configuration file. It's overkill in my opinion :-)
Re: YAML: probably not so great after all (2017)
#386Earlier quoted context omitted.
> JSON didn't exist (YAML is a parallel, contemporary effort). Interesting. How did it happen then that, quoting the YAML 1.2 spec, that "every JSON file is also a valid YAML file"? Although the previous spec documents don't mention JSON. Was that an intentional design decision for 1.2 or was it some kind of convergent design due to Javascript?
I have admired Douglas Crawford's excellent JSON from the moment I saw it, it is a model of simplicity. I also like TOML and wish it all the best. By contrast, YAML is complex and could use a hair cut. When I say "JSON didn't exist", what I mean is that it wasn't popular or known to us when we were working on YAML. So, please excuse my sloppy wording. For me, the work on what would become YAML started with a few of u…
"JSON didn't exist because Us and We"?
YAML is an invented serialization format, JSON is a discovered one. As CrOCKford points out, JSON existed as long as JS existed, he just called it out and put a name on it.
Anyway, XML is a strong anti-pattern (too much security, even if you get it right on your end, the other party likely screwed something up). YAML seems to be going down that path too.
TOML seems to be "the JSON of *.ini" (ie: discovering old conventions, rather than inventing new ones), and I'm glad to have been exposed to it.
Re: YAML: probably not so great after all (2017)
#387Earlier quoted context omitted.
> But how do you parse it without Lua? You wouldn't, but the language is lightweight enough (according to Wikipedia, the interpreter is ~180kb compiled) that including it as a dependency probably won't matter. It's less overhead than an interpreter for JSON or YAML at least. >Is a parser library available for mainstream languages? It's used commonly in game development so yes for C and C++, and the site[0] mentions "…
I know Lua and I use it sometimes (for example in Redis). But I don't want to include a full Lua interpreter in my program just to parse a configuration file. It's overkill in my opinion :-)
Fair enough, but it still seems like the language you're looking for, feature-wise.
Re: YAML: probably not so great after all (2017)
#388Earlier quoted context omitted.
I have admired Douglas Crawford's excellent JSON from the moment I saw it, it is a model of simplicity. I also like TOML and wish it all the best. By contrast, YAML is complex and could use a hair cut. When I say "JSON didn't exist", what I mean is that it wasn't popular or known to us when we were working on YAML. So, please excuse my sloppy wording. For me, the work on what would become YAML started with a few of u…
"JSON didn't exist because Us and We"? YAML is an invented serialization format, JSON is a discovered one. As CrOCKford points out, JSON existed as long as JS existed, he just called it out and put a name on it. Anyway, XML is a strong anti-pattern (too much security, even if you get it right on your end, the other party likely screwed something up). YAML seems to be going down that path too. TOML seems to be "the JS…
> "JSON didn't exist because Us and We"?
If you define JSON as the underlying practice that Crawford later named and documented, then sure, what I wrote reads completely wrong headed. However, when we were working on YAML, JSON was not yet called out and given a name.
I believe the most important convention that YAML and JSON shared was a recognition of the typed map/list/scalar model used by modern languages. Further, as far as conventions go, I think there's quite a bit to be said about languages that use light-weight structural markers such as: indentation, colon and dash.
Re: YAML: probably not so great after all (2017)
#389Earlier quoted context omitted.
> If your configuration file is a programing language this interface is not that well defined. While I do agree with the rest of your comment I don't think they were advocating using the full language for configuration, just the maps/arrays/etc. (e.g. Python's `literal_eval`).
true, but some user will use the full language. Something like: config = {'key1': 'value1', 'key2': 'value2'} could be written as: config = {} config['key1'] = 'value1' config['key2'] = 'value2' With large chunk possible between the 3. It basically transforms the configuration file into an API like any library, which is not really what you want for an end user program.
If a key objection/perceived threat is that this might give someone an insertion point they're not meant to use for code ... well, let's consider that we're talking about applications distributed as interpreted language source here. Disallowing code-as-config isn't even closing the door of this particular barn after the horse has left, it's putting two strands of police line tape across the bottom half of the gap where the door was never installed and hoping any equines thinking of passage politely consider the message in case it hadn't already occurred to them which side of the entrance they preferred to be on.
Consider this: Design and optimize for the common case.
Why do we have config files? Because developers actually want a place dedicated to simple or structured application configuration data, for which PHP assignments with arrays + primitives can function at least as effectively as JSON. Most developers would prefer that config data get loaded quickly so the application can get on to doing actual app-y things. Using the language for this means you're parsing at least as fast as you can interpret and you can also take advantage of any code caching that's part of your deployment (especially nice in the PHP-likely event that config settings would be reloaded with every request).
Abuse isn't likely to be the common case. The end users you invoked certainly aren't going to be the ones looking for opportunities to insert code over data. Developers have other places to put code and, as mentioned, probably actually want a place dedicated to data. You're still right that of course someone will do it, just like someone will inevitably create astronaut architecture hierarchy monstrosities in any language with classical inheritance or make potentially hidden/scary changes to language function using metaprogramming facilities.
But potential for abuse doesn't automatically mean a feature should be disallowed.
A lot of the time it's better to let people who can be circumspect have the benefits of a potential approach, and if somebody thinks they need to solve a problem by using a technique that's arguably abuse, well, let them either find out why it's a bad idea or enjoy having solved their problem in an unusual way. Not the end of the world. Possibly even legit.
Re: YAML: probably not so great after all (2017)
#390Earlier quoted context omitted.
XML is in that odd middle-ground where it's usually human-readable, but also a huge pain in the ass to write. It's great at what it was intended for, as a data interchange format. For a general-purpose human-writable structured data format, I guess the ugly nonstandard hack that is "JSON with comments" is probably good. It's certainly faster to parse than YAML.
I've managed to teach non-programmers to successfully edit YAML files without too much trouble, but most non-programmers have a really hard time consistently producing valid JSON by hand. As much as there is a lot to not like about YAML, it is the easiest one for humans to consistently write in my experience.
But why should they have to do it by hand?
We don't judge Excel and Librecalc by how easy it is to open their files and produce valid spreadsheets without good tooling.
If they're working with structured data, why can't they use tools/editors which work with the structure, reveal it, and enforce it?