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

YAML: probably not so great after all (2017)

arp242.net

Post reply on HN
Print view View original

141–150 of 412 posts

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

#141

Post by clarkevans »

allanbreyes wrote: post #131

I'd like to propose the "YAML-NOrway Law." "Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway." Example: NI: Nicaragua NL: Netherlands NO: Norway # boom! `NO` is parsed as a boolean type, which with the YAML 1.1 spec, there are 22 options to write "true" or "false."[1] For that example, you have wrap "NO" in quotes to get the expected result. This, along with many of the…

The implicit typing rules (ie, unquoted values) should have been application dependent. We debated this when we got started and I thought there was no "right" answer. Alas, Ingy was correct and I was wrong.

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

#142

Post by emodendroket »

blt wrote: post #77

YAML and TOML both seem too complicated. Automatic date parsing? So many different ways to specify the same nested hash table? I like json because there's usually one obvious way to do what you want. It's a local minimum, like C and Lisp. It's really too bad about the comments.

Way too much engineering time and energy has gone into handrolled, mutually-incompatible solutions for passing dates in JSON.

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

#143

Post by lomnakkus »

allanbreyes wrote: post #131

I'd like to propose the "YAML-NOrway Law." "Anyone who uses YAML long enough will eventually get burned when attempting to abbreviate Norway." Example: NI: Nicaragua NL: Netherlands NO: Norway # boom! `NO` is parsed as a boolean type, which with the YAML 1.1 spec, there are 22 options to write "true" or "false."[1] For that example, you have wrap "NO" in quotes to get the expected result. This, along with many of the…

This is a very good example of the problems of YAML and it's one of those things that has really preplexed me about the design of YAML. (I suppose it's a sign of the times when YAML was designed.)

It's[1] just so blatantly unnecessary to support any file encoding other than UTF-8, supporting "extensible data types" which sometimes end up being attack vectors into a language runtime's serialization mechanism, autodetecting the types of values... the list goes on and on. Aside from the ergonomic issues of reading/writing YAML files, it's also absurdly complex to support all of YAML's features... which are used in A well-designed replacement for certain uses might be Dhall, but I'm not holding my breath for that to gain any widespread acceptance.

[1] Present tense. Things looked massively different at the time, so it's pretty unfair to second-guess the designers of YAML.

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

#144

Post by cesarb »

kaslai wrote: post #42
minimaxir wrote: post #28

Semirandom question: what's the proper file extension for a YAML file? I've done informal polls on it and every time it's an even split between .yaml and .yml

There are plenty of file formats that have multiple extensions in common use. I can think of a few off the top of my head: - .jpg / .jpeg - .tif / .tiff - .htm / .html - .cpp / .cxx It's frustrating at times, but not all file formats have One True Extension.

Most of these are Microsoft's fault: MS-DOS allows only 3 characters for the file extension, so the file extensions had to be abbreviated.

As for C++, I'd also blame Microsoft. The plus character (+) is a reserved character for MS-DOS, so the obvious extension ".c++" couldn't be used (nor could the case-sensitive ".C" extension). So people either toppled their plus signs (".c++" becomes ".cxx"), or replaced them by the first letter of "plus" (".c++" becomes ".cpp"), or treated them as a repetition sign (".c++" becomes ".cc").

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

#145

Post by dokem »

weberc2 wrote: post #58
dokem wrote: post #45

Earlier quoted context omitted.

Python objects and JSON are practically identical.

In what sense could this be true? Python objects support a whole host of behavior; JSON is a data format. Python dicts might be a closer analogy except Python keys can be anything that is hashable while JSON requires strings, and of course Python dict values can be any Python value; not just the JSON analogs.

I think you are purposely mis-interpreting me. Python dicts are practically, syntactically identical to JSON. Yes, python dict values can be any python value the same way JSON in JS can be any JS value. Point being, someone coming from python would see JSON as identical to a python dict. We can run around in semantic circles all day.

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

#146

Post by jwilk »

bryanlarsen wrote: post #69

A thread hating on YAML without a mention of the bastardized YAML that ansible uses? Ansible extends yaml so that: cmd: a b c is actually but not quite identical to: cmd: ["a", "b", "c"] It also embeds JINJA2 templating part-way (!) through the YAML parsing process. The gotchas that these and other bastardizations cause is only partially documented at the bottom of this page: https://docs.ansible.com/ansible/latest/r…

Another example of YAML-but-not-quite is Travis CI configuration format:

https://github.com/travis-ci/travis-yml#user-content-yaml

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

#147

Post by lostctown »

twodave wrote: post #54
mschuster91 wrote: post #36

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.

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…

Interesting approach.

Maybe I'm lazy but avoiding increasing cost to commenting is one of the few absolutes I abide by. Often I find myself tired after a long stretch of code, trying to convince myself that's it's understandable on it's own.

This is one of those systematic rules I have to enforce to shutdown my lazy lizard brain.

edit: But I can see how highly structured comments could actually come in handy as well for viewing configs in a gui

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

#148

Post by Zardoz84 »

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 paragraph"
    		paragraph "This is the second paragraph"
    	}
    }

    // Anonymous nodes are supported
    "This text is the value of an anonymous node!"

    // This makes things like matrix definitions very convenient
    matrix {
	1 0 0
	0 1 0
	0 0 1
    }
```

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

#149

Post by [deleted] »

jerrac wrote: post #81

A couple thoughts. If your configuration file is so long it's unreadable in YAML, then maybe you need to break it up into more than one file? I can't imagine any syntax would be easy to read once you reach more than 100 or so lines. Do any configuration file languages support type hinting? Adding (int) in front of a YAML key would be easy enough to read, and would keep some of the confusion at bay.

[deleted]

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

#150

Post by mkobit »

bryanlarsen wrote: post #69

A thread hating on YAML without a mention of the bastardized YAML that ansible uses? Ansible extends yaml so that: cmd: a b c is actually but not quite identical to: cmd: ["a", "b", "c"] It also embeds JINJA2 templating part-way (!) through the YAML parsing process. The gotchas that these and other bastardizations cause is only partially documented at the bottom of this page: https://docs.ansible.com/ansible/latest/r…

SaltStack also has the JINJA2 template embedding which can make it very difficult to understand which parts of the lifecycle run through templating. I'm still not certain I understand how it works.

The most recent offenders for bastardizing YAML I have seen are the different CI services:

* Circle CI using moustache-like templating and interpolation with things like {{ .Branch }} available in certain steps [1]

* GitLab CI adding an "include" type directive to declare YAML dependencies [2]

I've also experienced this professionally. At my last company, somebody decided to add a feature to enable interpolation in some parts of the YAML deployment data. It ended up being used by a handful of people who were confused why interpolation worked in some places and not others. The weird trend of "extending YAML" seems to be going against any sort of benefits you might have by trying to use it.

[1]: https://circleci.com/docs/2.0/configuration-reference/#save_...

[2]: https://docs.gitlab.com/ee/ci/yaml/#include

Post reply on HN