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

Fear and Loathing in YAML

chrisshort.net

Post reply on HN
Print view View original

101–107 of 107 posts

Re: Fear and Loathing in YAML

#101

Post by inshadows »

samatman wrote: post #6

TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…

Exactly what does it solve? You ditch one configuration language for another (less feature rich) one, and then do imperative programming in it anyway.

Re: Fear and Loathing in YAML

#102

Post by bionhoward »

We should all just write our config in JavaScript or TypeScript because then we can standardize around a common interface language.

It’s simple, widely known, has comments, not dependent on white space, JSON has the right types we need program (and can be validated, with JSON Schema).

Critically, to generate configs, we can write loops, conditions, ternaries, functional programs with Ramda, classes/OOP, and even fancy GUIs. Simple English JavaScript is powerful and readable.

.js is the move here... especially once node supports immutable data structures

This is why stuff like AWS CDK and Pulumi are legit. Configure your stuff with actual code.

All we gotta do is fill the gap between JS and Python in terms of scientific computing, and we’re set. Typescript->WASM could be interesting.

I’m sure there are some details that make this difficult but, what do you guys think about standardizing around JS/TS?

Re: Fear and Loathing in YAML

#103

Post by jchw »

dimitropoulos wrote: post #97
dragonwriter wrote: post #52

Earlier quoted context omitted.

JSON is a subset of YAML, so if you want to write YAML like JSON you can, and you can even automatically convert from JSON style to more idiomatic YAML, or vice-versa, with appropriate tooling.

despite how popular this claim is, it is not true. The following is a valid JSON document according to the spec[1]: { "key": "value", "key": "otherValue" } But is not a valid YAML document[2], something addressed in the spec itself. The JSON spec says > The names within an object SHOULD be unique. And `SHOULD` is defined by RFC 2119[3] as > This word, or the adjective "RECOMMENDED", mean that there may exist valid re…

Hey dimitri, what's up.

JSON is not 100% a subset of YAML, this is true; that's slightly a simplification of the truth that is commonly echoed. It is a syntactically a subset of YAML, and for anything representable in JSON you can still do a functionally-lossless translation* from JSON to YAML and back again. This is because:

> In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten.

So,

    { "key": "value", "key": "otherValue" }
becomes

    { "key": "otherValue" }
in a round trip, but represents the same thing, going by ECMA262 rules.

These are definitely distinct snippets of JSON and if you only use RFC4627 then it doesn't define anything about how to parse the JSON beyond the syntax, whereas the YAML spec is a bit more complete in regards to specifying semantics probably partly since it's a more complicated language. Thankfully in the common case most JSON parsers do as specified in ECMA262 (which makes sense since that's where this format came from anyways) and use the latest key. You can see this in Go's "encoding/json" for example. So this property is still meaningfully true, I'd argue, even if it is more nuanced than commonly believed.

tl;dr: It is true that not all valid JSON is valid YAML. However, automatic translation between the JSON and YAML is still possible if you are going by ECMA262 JSON semantics.

P.S.: In practice, YAML parsers do actually often take the liberty of interpreting YAML to be a proper superset. This isn't too surprising since most YAML parsers take a lot of liberties that are/were outright spec violations, but just as an example, here's PyYAML:

    >>> from yaml import load
    >>> load('{"a":"1","a":2}')
    {'a': 2}

Re: Fear and Loathing in YAML

#104

Post by afiori »

saghm wrote: post #24
ben509 wrote: post #13

Earlier quoted context omitted.

Another comment brought up StrictYAML, and they have a good dissection of the problems with TOML[1]. Personally, after doing a few pyproject.toml files, I still find it confusing and awkward as soon as you get past simple headers and key-values. TOML is like YAML, it translates to "jsonic" types, but JSON's virtue is that simple 1:1 mapping between syntax and data. TOML and YAML both have non-obvious syntax and there…

IMHO the arguments in your link aren't particularly convincing. The three main points seem to be verbosity (defined in terms of total number of characters for a given file, which is not nearly as important to me as readability), not having indentation be significant (which might be downside to a Python programmer but feels like a win to me), and having explicit syntax to distinguish between types (e.g. strings being…

The second point is not about whitespace, but rather about how you can write your document out of order.

specifically TOML supports a syntax that allows to write documents like: (not actual syntax)

    a.b=1
    a.c=2
    d=3
    a.e =4
that would translate to {a:{b:1,c:2,e:4},d:3}.

So the criticism is that (in various cases) you need to read the entire document to be sure to have fully parsed one subtree of the document.

Re: Fear and Loathing in YAML

#105

Post by samatman »

inshadows wrote: post #101
samatman wrote: post #6

TOML remains severely underrated, for some reason. It's easy to read, easy to write, trivial to map onto JSON, and refreshingly clear of footguns. There are comments! If you get to pick your format for a configuration language, start by trying to talk yourself out of TOML. You'll probably fail; I'm interested to hear if folks out there have examples of something TOML is bad at, because I didn't come up with any when…

Exactly what does it solve? You ditch one configuration language for another (less feature rich) one, and then do imperative programming in it anyway.

Depends on what you're doing, right?

Dhall is going to be better than writing an inner-language monster of a config language, in YAML, TOML, or JSON. Let someone else do the work, I agree.

But if the goal is to have a human-editable file that loads a few values into a map, and it often is, TOML is pretty nice.

I think we've all been burned by 'configuration languages' which take on the complexity of a full programming language, in a worst-of-both-worlds sort of way. But sometimes you just want to change a font, or specify tabs-or-spaces, or set a non-default remote.

Re: Fear and Loathing in YAML

#106

Post by thunderbong »

dragonwriter wrote: post #52
tofflos wrote: post #39

Am I the only one who finds YAML much harder to write than JSON or XML? It's not just the fact that I get the syntax for lists and maps confused all the damn time. The worst part is that I'm unable to use the keyboard shortcut for automatically formatting my document! I love that keyboard shortcut! I hate being without it! I'm certain it represents more than half of my key presses in other languages! I type a few cha…

JSON is a subset of YAML, so if you want to write YAML like JSON you can, and you can even automatically convert from JSON style to more idiomatic YAML, or vice-versa, with appropriate tooling.

When I read this, I didn't believe it. I needed to prove this to myself!

I've seen and used YAML files for configurations in many places and I've always found editing YAML files by hand too much of a pain. It's very easy to miss a space and screw everything up. However, writing JSON directly into a plain text file is totally easy.

So, I created a normal text file named 'array_of_objects.json' like this -

  [
   {
    "first": "one"
   },
   {
    "second": "two"
   }
  ]
And then I wrote a ruby program to read it -

  require 'json'
  require 'yaml'
  
  array_of_objects = YAML.load_file 'array_of_objects.json'
  p array_of_objects
And I see the output as -

  [{"first"=>"one"}, {"second"=>"two"}]
I still can't get over it. I'm thinking of the countless hours wasted!!

Thank you so much.

Re: Fear and Loathing in YAML

#107

Post by inshadows »

samatman wrote: post #105
inshadows wrote: post #101

Earlier quoted context omitted.

Exactly what does it solve? You ditch one configuration language for another (less feature rich) one, and then do imperative programming in it anyway.

Depends on what you're doing, right? Dhall is going to be better than writing an inner-language monster of a config language, in YAML, TOML, or JSON. Let someone else do the work, I agree. But if the goal is to have a human-editable file that loads a few values into a map, and it often is, TOML is pretty nice. I think we've all been burned by 'configuration languages' which take on the complexity of a full programmin…

I have never been burned by the configuration language complexity. I'm constantly being burned by its limitation. You are right that for configuration TOML is OK. But the linked article talks about YAML in context of stuff like Ansible or K8s, where usually plain and simple imperative programming is coerced in YAML syntax.
Post reply on HN