Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

Post reply on HN
Print view View original

121–130 of 412 posts

Re: YAML: probably not so great after all (2017)

#121

Post by hobbescotch »

0xbadcafebee wrote: post #85

Years ago I had to support a tool that used YAML as a configuration language, and a transport between different applications. Holy. Hell. First of all, don't ever try to edit a YAML file by hand. You will introduce whitespace or other characters that will break the file, and you will not know until you run it and it breaks something. The reason you will not know? Not all YAML parsers are the same. Some will interpret…

I’ve been using python enums to store static, non sensitive config lately. Let’s me store my data in dict/JSON like format while being able to write comments. Plus no need to do any IO to access variables! However, not really sure if this is was the intended use case for python enums.

Re: YAML: probably not so great after all (2017)

#122

Post by wolfgang42 »

GordonS wrote: post #92
furgooswft13 wrote: post #62

Earlier quoted context omitted.

Not just trailing commas, but the need for commas at all when there is a newline right next to it has been a source of many stupid issues for me when less knowledgeable/experienced people edit json based conf files. Then there is floats without a leading zero. Missing colon after the key. And yea, naked keys. The need to wrap the entire file in { } or [ ] is just icing. Honestly I feel the most bare simple conf forma…

> but the need for commas at all when there is a newline right next to it JSON is often minified though - you're going to need something to use as a delimiter

Newline and comma are both 1 byte. You could specify that either is acceptable.

Actually, I think you could leave out the delimiter altogether and still be syntactically unambiguous, since quotes are required around keys:

    "key1":"value1""key2":2.75"key3":true"key4":"whatever"
though this looks terrible and there's probably some edge case I've forgotten. (Also it misses the point of JSON in that it's no longer valid JS. I don't know whether that's important anymore since you should be calling JSON.parse() not eval() anyway.)

Re: YAML: probably not so great after all (2017)

#124

Post by commandlinefan »

organsnyder wrote: post #105
commandlinefan wrote: post #32

Earlier quoted context omitted.

I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this: ApplicationName WhizBang ... So that they could pass schema validation and still have some hope of extensibility.

Why not just ?

That's still worse than WhizBang. Or

    ApplicationName=WhizBang

Re: YAML: probably not so great after all (2017)

#125

Post by clarkevans »

bhaak wrote: post #72
clarkevans wrote: post #34

One thing to remember is that YAML is about 20 years old. It was created when XML was at peak popularity. JSON didn't exist (YAML is a parallel, contemporary effort). Even articulating the problems with XML's approach was an uphill battle. What you would replace it with is also hard. What use cases matter? What is the core model? A simple hierarchy? Typed nodes? A graph? What sort of syntax is needed for it to be usa…

> 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 us in 1999 (from SML-DEV list). In January of 2001 we picked the name and had early releases. It took a few years of iteration before we had a specification the collaborators (Perl, Python, and Ruby) could all bless.

Anyway, with regard to Crawford's excellent work, JSON. It is a coincidence that YAML's in-line format happened to align. Although, it's probably because of a "C" ancestor, not JavaScript. The main influence on the YAML syntax was RFC0822 (e-mail), only that from my perspective, it needed to be a typed graph. In fact, we documented where we stole ideas from, to the best we could recall at that time: http://yaml.org/spec/1.0/#id2488920.

Re: YAML: probably not so great after all (2017)

#126

Post by dmitriid »

Edmond wrote: post #118
dmitriid wrote: post #108

Earlier quoted context omitted.

The answer is a marketing website with market-speak all over the page and 'Executable not found "/eula"' when trying to read Terms and Conditions? Edit: I actually did download whatever this thing is. What is this thing? The README is Jetty's README. There are dozens of dirs with crap^W code in them. It really is an answer to YAML/JSON, surely.

thanks for the broken link pointer, it will be fixed. the "So Much More" button is a link to the docs:) Here's the ConfigNode doc: http://codesolvent.com/doc/config-node/ The platform doc: http://codesolvent.com/doc/webapps/ If you're interested, send me an email (in my profile).

> the "So Much More" button is a link to the docs:)

Yeah... No. It looks like a link to yet more marketing-speak, and the page it links to answers zero answers as to why I would ever want it.

Hiding the product README in some nested folder in the source code is also a brilliant idea.

So, nope. I’m sticking to my YMLs and EDNs.

Re: YAML: probably not so great after all (2017)

#127

Post by [deleted] »

frou_dh wrote: post #119
xnxn wrote: post #97

Earlier quoted context omitted.

> Douglas Crockford originally specified the JSON format in the early 2000s

> I discovered JSON. I do not claim to have invented JSON because it already existed in nature. What I did was I found it, I named it, I described how it was useful. I don’t claim to be the first person to have discovered it. I know that there are other people who discovered it, at least, a year before I did. The earliest occurrence I found was there was someone at Netscape who was using JavaScript array literals for…

[deleted]

Re: YAML: probably not so great after all (2017)

#128

Post by hyperman1 »

commandlinefan wrote: post #32
tootie wrote: post #2

We've spent like 10 years trying to fill in gaps left when we all decided to hate XML. JSON is great as a lightweight DIF between trusted partners. If you care about maintenance and safety, XML with XSD is rock solid.

I don't know, XML is awfully verbose and the schemas are even more verbose. I've lost track of how many "XML" configuration files that looked like this: ApplicationName WhizBang ... So that they could pass schema validation and still have some hope of extensibility.

A few weeks ago, I had about 100 config files (tomcat context.xml) which all needed fixes for common misconfigurations - if they had the misconfigurations in the first place The kind of problem that is just a little bit too hard for search and replace. It was really easy with xslt. The result had all comments preserved. I choose to reformat the files, but keeping whitespace was an option too. Now tell me if you can do that with json,yaml,toml. Most parses simply forget about the comments to begin with.

In the same way, if we receive a data transfer in XML and there is a schema, simple validation catches a lot of problems quickly. You'd be surprised how many times a company gives you a schema and then sends you xml which doesn't validate. In JSON, you have to write a program to get even basic validation.

Don't get me wrong: XML has problems, some inherited from html/sgml (entities!), and even more after serious abuse by consultants, archicture astronauts and enterprise vendors (SOAP! namespace overuse! 10 XML parsers in 1 app!). But it was also miles better than what came before and I feel the XML hatred pendulum has swung too far.

Today, JSON is in vogue, and I've seen enough IT to not swim against the tide. It is a reasonable solution for problems caused by XML abuse. Besides, there is value in going with the majority,even if it only fixes 80% of your problem. But I can only weep for the miserable date, numeric and comment support, and their endless stream of incompatible workarounds.

For your parameter example: You can't both strictly validate and have full freedom at the same time. Something has to give a bit. Some less horrible alternatives I've seen:

  

   , add newline for each  attribute

  value

Re: YAML: probably not so great after all (2017)

#129

Post by tomxor »

I'm not saying YAML is perfect or terrible (just like the author), however most of the examples the author gives are going to be the same for any language attempting to implicitly type values.

I think maybe YAML just went a bit too far: because everyone hates defining key names with quotes when it's unnecessary 99% of the time, but it would have been enough to relax that rather than go all the way to suggesting relaxing all quotes and then attempting to infer value types.

Re: YAML: probably not so great after all (2017)

#130

Post by kodablah »

ngrilly wrote: post #75

JSON + comments + trailing commas + naked keys + multiline strings would be a great alternative. Maybe something like JSON5.

You'd really like HOCON[0] then. Just a bit too complicated to see wide adoption I'm afraid.

0 - https://github.com/lightbend/config/blob/master/HOCON.md

Post reply on HN