Live data from Hacker News

YAML: probably not so great after all (2017)

arp242.net

221–230 of 412 posts

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

#221
post #74

Earlier quoted context omitted.

> 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 trailing comma. I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.

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

The lack of template string support is a weird part of that.

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

#222
post #20
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…

In contrast, JSON is super intuitive and basically self documenting. Personally I've found the exact opposite when dealing with 'normal' people. Most people can get basic YAML, but unless they're a programmers (or at least know how to program) most people fail miserably at writing JSON by hand.

JSON has too many rules regarding comma placement.

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

#223
If the problem YAML is size / formatting, that's something a good IDE can simplify even more. For loading up configs that would otherwise be properties files, I have found it to be quite clean. If you think of it a domain language for configuration, YAML is great. It can be understood pretty much intuitively, and it does some things quite well. On the other hand, when it comes to exchanging data, JSON > XML > X12 EDI... EDI? Yes, it's still a thing... a terrible thing...

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

#224

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…

I don't get the matrix example. Why is it different from key 1 with multiple values 0, 0, and key 0 with values either 1, 0 or 0, 1?

SDL identifiers start with a letter or underscore, and a key must be a valid identifier.

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

#225

I enjoy HOCON btw. Are there other configuration languages that any of y’all like?

There's this half baked one I built once because we wanted untyped config and had never heard of JSON

https://github.com/EamonnMR/Zond/blob/master/RedShift/src/co...

It ends up looking like this: https://github.com/EamonnMR/Zond/tree/master/RedShift/assets...

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

#226
post #206
post #191

Earlier quoted context omitted.

I am the author of this article. Apparently people read my website (how they get there, I don't know?) At any rate, it's worth mentioning that in the conclusion I wrote: > Don’t get me wrong, it’s not like YAML is absolutely terrible but it’s not exactly great either. I still use YAML myself even when I have the freedom to use something else simply because – for better or worse – it's very widespread, and for many ta…

I love the clean style of your website.

Thanks! Last time I checked my domain got penalized for having abnormal low markup or some such, which apparently makes it look like a spam site. I am proud of this.

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

#227
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.

> difficult to pull off and requires productization, in other words not low-level tooling in a text file. Is this supposed to be a feature? One of the great things about simple config files is that you can use standard GNU tools to view edit, and diff them, you can put them in source control, you can be sure that you can edit them on a remote server no matter what's installed, etc. Eliminating all those benefits woul…

You're right regarding the value of text files. ConfigNode is really for management of configurations for use cases where you can have huge JSON/YAML files and you want to be able to manage them, facilitate dynamism (often using templates)...support collaboration..etc...it is a gold-plated solution and not necessarily suitable for simpler needs.

Here's another example of ConfigNode used to manage Akamai configurations:

https://youtu.be/gcPAmpKo9fs

Akamai configurations can be very complex and need to be maintained and managed, you can't really do that effectively using text files.

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

#228

Anyone here use Swagger? Do you write your definitions in JSON or YAML?

I generate Swagger/OpenAPI files, and use YAML because it's easier to read.

If I had to write OpenAPI files manually I'd probably choose to jump out of the window.

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

#229
post #171

Earlier quoted context omitted.

well there is also toml and hocon (json supersets) which are "yaml like"

TOML is more like ini than YAML. I don't like it because it uses the = symbol which seems imperative rather than declarative. (Same with HCL, it might be a nitpick but these are languages I'm going to be using all the time.) HOCON is interesting but at first glance it seems it might be too ambiguous for my tastes, because like YAML, because it supports both js-style ("//") and shell-style ("#") comments. JSON plus co…

I'd argue that = only feels imperative if you're used to imperative languages. Prolog and Haskell, both of which focus on being declarative, also both use the equals sign.

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

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

You know what else is human readable, easy to parse if you're using PHP, and supports comments? PHP. I understand why some languages rely on common configuration file formats. I don't understand why the popular dynamic script-y languages don't more commonly use the natively-expressable associative/list data structures that they're famous for making convenient.

I think some of it is PLOP (Principle of Least Power).

$CFG = random() > 0.5 ? "yes" : "no";

...is likely "too powerful". It'd be nice if there were ways in certain programming languages to do something like "drop privileges" to avoid loops, function calls, external access, etc.

Post reply on HN