Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

361–370 of 412 posts

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

#361
post #305

Earlier quoted context omitted.

JSON5 is also a great alternative: https://json5.org/ Supports comments, trailing commas, single quotes, multi-line strings, and more number formats.

I really wished json5 would support optional commas as well. If you have a new line, no comma needed. So you can do [ 1 2 3 ] New lines used by humans, computers should do a good job as well.

Like https://hjson.org/?

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

#363

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" became popular in the 90s. They were http requests which returned javascript which you would simply eval(). No need to write or import a parser, and it is the same syntax as the language you're using, because it is the same language. In technology many things become popular not because how good (or bad) things are, but how easy to use something is.

Can't agree more. In tech, the prime mover often becomes the standard.

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

#364

Earlier quoted context omitted.

> There's no language that I'm aware of that can natively generate PHP syntax This is a solid argument against using PHP (or any such language) as a cross-language data interchange format. There are others :) And I totally agree you want a language independent format for anything you might have to feed across an ecosystem of tools. For a PHP-system generating/altering its own config files... PHP's `var_export` genera…

You don't know when you'll need to generate or parse your config files with something that either can't read, write or execute your language. Django's settings.py sucks. I've used Django since the 0.9 days. It's extremely impractical and needs to be worked around constantly.

Settings.py is uniquely bad, though, IMO because it tries to be a badly defined dict(), instead of exposing proper configuration interfaces. Ruby config files are common and usually fairly great, see for example the Vagrantfiles.

And you won't have to generate your config files (parsing, maaaaaybe), because those needs are covered by the fact that the files are programs. They are _already_ generating a configuration.

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

#365
We used YAML from the start in Wrench tool for writing reftests for WebRender[1]. Currently looking into a prospect of migrating all of them to RON[2] as a better alternative, which has proven itself useful in WebRender captures.

  [1] https://github.com/servo/webrender/
  [2] https://github.com/ron-rs/ron

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

#366

Earlier quoted context omitted.

If you're going to do this kind of thing why would you not add a standard date format

Just use a string and ISO 8601? “2018-03-25”

Wow, I can "just" use that, thanks. The problem is that JSON is an interchange format, meaning that I need to implement this serialization and deserialization quirk on every producer/consumer of my API (which, you know, avoiding is kind of the point of using a standard interchange format). Furthermore, because everything is a string, I can't unambiguously indicate something is meant to be a string in that format rather than a date.

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

#368

For config formats I'm finding HCL[1] to be nice for my use cases. It has comments, no requirement for double quoted identifiers, and is actually simple. The main issue was the only implementation is in Go, so I had to write a port to C++. [1] https://github.com/hashicorp/hcl

Super happy with HCL for over a year in production now.

I've only got one FOSS project using HCL but I think of its' bundled HCL config file is an attractive part of its UX: https://github.com/LukeB42/psyrcd

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

#369

Earlier quoted context omitted.

Thank you for StrictYAML I might just use it. It does look like a nice hair cut. You might wish to give Ingy a ring. He has been itching to move forward on a reduced/secure YAML subset. That said, StrictYAML seems to be a tad bit more of a hair cut than I'd imagine. I'd keep nodes/anchors, since I think a graph storage model is underrated; I think that data processing techniques just haven't caught up with graph stru…

Great to have you here elaborating on various design choices. Are you perhaps familiar with OGDL [1] and what's your opinion? [1] http://ogdl.org/spec

I don't have much to suggest. For YAML, the use of whitespace, colons and dashes primarily emerged from usability testing with domain experts who are not programmers. In particular, testing was done in the context of an application that needed a configuration and data auditing interface, an accounting application. Even anchors/aliases worked in this context and supported the application's use by making the audit records less repetitive without introducing artificial handles.

Other use cases such as dumping any in-memory data structure from memory, perhaps out of a sense that we needed full completeness, actually didn't have any end-user usability testing. Round-tripping data seems in retrospect to be a diversion from the primary value that YAML provided.

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

#370
post #321
post #63

Earlier quoted context omitted.

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

Is there a yaml parser that preserves comments and a writer that manages to write them back though?

The parser linked from the article does: https://github.com/crdoconnor/strictyaml
Post reply on HN