Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

111–120 of 412 posts

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

#111
post #6

With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end. In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trail…

> objects can't have a trailing comma

This has caused me so much misery in the past, especially since none of the tools will tell you which line the offending comma is on. Great, somewhere in my thousand-plus-line JSON file is a tiny syntax error but you won't tell me where.

Ended up having to regex for them. Didn't do wonders for my trust in JS tooling.

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

#112
post #92

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

A newline character is just as minimal as any other ASCII delimiter.

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

#114

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 the age-old question, isn't it?

Your option is better, but XML is very (maybe too) flexible and is bound to be made a mess of.

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

#115
> Don’t get me wrong, it’s not like YAML is absolutely terrible – it’s certainly not as problematic as using JSON – but it’s not exactly great either.

Well at least it's the least worst then, do that make it the best?

Frankly I hope the future will be make with indented languages. Curly braces languages often allows too much liberty, and it's annoying. The fact that go enforce the curly brace style is really the tipping point of curly brace languages.

Granted there need to be some good compromise for ambiguous details when parsing an indented syntax, but readability matters much more than anything to me.

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

#116
For a serious take on configuration file format it might be worth checking out Dhall.

Dhall has schemas, types, imports, and even functions (though it doesn’t let you write code that would e.g. loop infinitely).

You can even use an executable[0] to compile Dhall to YAML and JSON, excluding unsupported features such as functions.

[0] https://github.com/dhall-lang/dhall-lang/blob/master/README....

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

#117
post #92

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

I would hope minified JSON is not being used for conf files.

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

#118
post #41

Object graphs are the answer to the endless iteration on the right config format: http://codesolvent.com/config-node/ it is however difficult to pull off and requires productization, in other words not low-level tooling in a text file.

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

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

#119
post #97

Earlier quoted context omitted.

JSON definitely did exist 20 years ago.

> 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 doing data communication as early as 1996, which was at least 5 years before I stumbled onto the idea.

https://www.youtube.com/watch?v=-C-JoyNuQJs

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

#120

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…

[deleted]
Post reply on HN