Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

181–190 of 412 posts

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

#181
post #63

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…

Drupal 8 uses YAML* as its configuration language because JSON doesn't support comments. That simple. Thank you for YAML, it does deliver for us: it's human readable and it's easy to parse (see below). * I mean, it uses an ill defined subset of YAML. The definition is "whatever the Symfony YAML parser supports".

VS Code uses JSON with comments for config files. [1]

Technically, this is not JSON. You won't be able to use a standard JSON parser without stripping comments first. But you can use a simple, JSON-like language with comments for config.

[1] https://code.visualstudio.com/docs/languages/json#_json-with...

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

#182
post #96
post #74

Earlier quoted context omitted.

JSON5 supports comments, and is only slightly more complex than JSON. https://json5.org/

The barrier here would be whether there's support in enough implementations to feel safe using it in the wild, which I'm guessing will take a while at the very least.

What’s incredible here is that we’re not at the beginning of programming, when we built temporary languages that ended up becoming forgotten. Web may be a final form of IT, Angular may be the « right », the final, the perfect way to build applications even in 50 years, just like HTML has become the final way to build websites for the last 25 years, JSON may make legacy, and my grandson might even struggle with parsers that still use JSON instead of this new tech called JSON5...

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

#183

No body talks about SDLang (Simple Declarative Language) : https://sdlang.org/ An example : ``` // This is a node with a single string value title "Hello, World" // Multiple values are supported, too bookmarks 12 15 188 1234 // Nodes can have attributes author "Peter Parker" email="peter@example.org" active=true // Nodes can be arbitrarily nested contents { section "First section" { paragraph "This is the first parag…

Interesting. They don't seem to have a python implementation surprisingly.

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

#184
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…

According to Platonism, JSON has no spatiotemporal or causal properties (like a datetime format) and thus has existed and will exist eternally. All hail JSON.

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

#185

I've been playing with Home Assistant[0] recently and, as a result, getting exposed to YAML. I don't find it pleasant to work with at all. I'm sure a big part of that is how Home Assistant uses YAML for automation stuff[1] that would probably be better served by a real programming language. I think a big part of the unpleasantness comes from how non-obvious some things are. For example, why does the first automation…

I agree. This is my biggest issue with YAML - the syntax is just so weird and unintuitive. Compare arrays in YAML to JSON. YAML makes no sense.

Then there is the significant whitespace, difficult to remember quoting rules, etc.

I think the only reason it had gained any traction is because it is relatively easy to write multi-line strings in, so it is good for shell scripts, e.g. in CI configuration.

Someone should really come up with a sane alternative that works well for that use case though.

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

#186
post #75

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

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.

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

#187

Earlier quoted context omitted.

How do I do something like: { # comment with a note about the value of foo "foo": "bar", # comment with a note about the value of baz "baz": "qux" } Without driving myself and future readers insane with fooComments and bazComments? What if I need a multiline comment explaining a yak-shaving story for why a key is set to a certain value? What if the object in question is a set of keyword arguments, and adding new fiel…

Ok, I'll bite. { "#": "A foo variable", "foo": true, "#": "A bar variable", "bar": false } Alternatively. { "# A foo variable": "", "foo": true, "# A multiline..": "", "# .. bar variable": "", "bar": false } Presto!

Sigh. All I wanted to do is to say thanks for the YAML standard -- comments are important but not the only problem with JSON. And truly I can't be expected to remember all of this discussion from like six plus years ago. One thing I remember though, it the trailing comma problem -- we upstreamed a grammar change to Doctrine annotation so "foo, bar," is OK because PHP arrays accept that and it's bonkers trying to code a mostly PHP system without trailing comma support. Also, JSON is no fun to write , you need to have [] {} all correct where YAML is much easier. The less sigils the better and most of Drupal YAMLs only use the dash, the colon and the quote. This is the grave mistake Doctrine committed as well, instead of simple arithmetic (>=1.0) they used mysterious sigils in version specification (~1.0). Drupal is in the business of constantly accepting new contributors and (~R∊R∘.×R)/R←1↓ιR is not newbie friendly, no matter how you slice and dice it. There are certainly advantages of sigil heavy languages like APL and Perl but the scare factor is too high.

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

#188
post #132
post #54

Earlier quoted context omitted.

In our JSON config files we do: { "ConfigKeyComment": "This is for blah blah blah", "ConfigKey": "Foo" } Obviously this wouldn't work in all cases (you're putting more work on your parser to interpret unused keys basically), but if we're talking config files specifically, I see this as an acceptable approach since there's little chance you'll be parsing such files more than once each (plus, writing a simple tool to s…

I've tried something similar but found it way too painful if the comments need to be long... # Never enable this config, because if you do the space-time # continuum will collapse into itself and the cloud servers # will disappear in a puff of steam. However, if you really # must enable it, remember that it's boolean and go read # TICKET-8675309 for the extensive list of side effects. TurboFactorRenoberation = false…

That's not JSON anymore, that's pretty much enough to be considered a unique DSL. Scary that this is more or less required.

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

#189
I recently posted about a technique I've been developing (and am very happy with) for representing and editing JSON in spreadsheets, without any sigils, tabs, quoting, escaping or trailing comma problems, but with comments, rich formatting, formulas, and leveraging the full power of the spreadsheet.

https://news.ycombinator.com/item?id=17309132

>Recently I've been working on kind of the converse of this problem with JSON and spreadsheets, and I'll briefly describe it here (and I'll be glad to share the code), in the hopes of getting some feedback and criticism:

>How can you conveniently and compactly represent, view and edit JSON in spreadsheets, using the grid instead of so much punctuation?

>The goal is to be able to easily edit JSON data in any spreadsheet, copy and paste grids of JSON around as TSV files (the format that Google Sheets puts on your clipboard), and efficiently import and export those spreadsheets as JSON.

>[...]

Since I wrote that post, I've cleaned up and refactored the code into a portable little library that will run in the browser, or inside of Google Sheets:

https://github.com/SimHacker/UnityJS/blob/master/UnityJS/Ass...

Here's an example spreadsheet (also check out the examples in the other sheet tabs):

https://docs.google.com/spreadsheets/d/1nh8tlnanRaTmY8amABgg...

I haven't come up with a trendy marketing name for it yet (except for the source file name sheet.js), because I think it's important to first discover what it is by using and refining it for a while, writing some documentation to explain it, and getting feedback from other people (work in progress), before trying to name it -- otherwise you might end up calling it "Yet Another ".

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

#190

I continue to hold a firm belief that the reason JSON is so popular is that it covers most use cases without any of the dumb crap that hides in YAML and XML behavior.

Yes. YAML and XML do way more than a config format needs. You need key value pairs and basic structures (variables, arrays and maps) and types.

JSON is lacking in some respects but it's still really close to perfect for its use case.

Post reply on HN