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

81–90 of 107 posts

Re: Fear and Loathing in YAML

#81

Post by dragonwriter »

bobbylarrybobby wrote: post #71
goatlover wrote: post #68

Earlier quoted context omitted.

But it hasn’t hurt Python popularity.

Personally it’s one of reasons I’m using python less and less and JavaScript more and more. I just can’t stand the white space.

The difference between Python and YAML is that Python doesn't have a semantically-equivalent, non-indentation-sensitive presentation style. How you choose to view and work with YAML is a choice that doesn't need to have any impact on what you share with others and how they choose to view and work with it.

While I'm not usually fond of “you're holding it wrong” arguments, that's pretty much the proper response to complaints about YAML’s indentation sensitivity, since you can work with YAML in a style which isn't indentation sensitive without anyone you share data with seeing anything different.

Re: Fear and Loathing in YAML

#82

Post by cageface »

dragonwriter wrote: post #80
cageface wrote: post #53

Earlier quoted context omitted.

Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. Being able to reliably reformat hundreds of lines of code with a single keypress is far more valuable than a few saved braces.

> Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. In some contexts, sure, which is one reason why YAML has two presentational styles with equal semantic power, between which a suitable tool can convert mechanically, and only one of those two styles features whitespace sensitivity. > Being able to reliably reformat hundreds of lines of…

If Python & Haskell had this I'd be more inclined to use both of them.

Re: Fear and Loathing in YAML

#83

Post by dragonwriter »

cageface wrote: post #82
dragonwriter wrote: post #80

Earlier quoted context omitted.

> Significant whitespace seems like a good idea and looks great in small examples but it has some very serious downsides in real use. In some contexts, sure, which is one reason why YAML has two presentational styles with equal semantic power, between which a suitable tool can convert mechanically, and only one of those two styles features whitespace sensitivity. > Being able to reliably reformat hundreds of lines of…

If Python & Haskell had this I'd be more inclined to use both of them.

> If Python & Haskell had this I'd be more inclined to use both of them.

Haskell does.

https://en.m.wikibooks.org/wiki/Haskell/Indentation

Re: Fear and Loathing in YAML

#84

Post by kstenerud »

slifin wrote: post #30

In a world where there's only a few primitive types no one can share uuids or dates across the wire without both sides knowing which fields are dates or uuids ahead of time JSON is too simple we need more primitive types and an extensible data notation to formalise data sharing of unknown types

I had the same complaints, thus https://concise-encoding.org/

Re: Fear and Loathing in YAML

#85

Post by doteka »

ben-schaaf wrote: post #74
ddevault wrote: post #64

Earlier quoted context omitted.

Correction: YAML is a superset of JSON

To explain the downvotes: JSON ⊆ YAML implies YAML ⊇ JSON. You're saying the equivalent of "3 > 1 is wrong: 1 < 3".

What Drew is saying is absolutely correct though. YAML was specifically designed to be a superset of JSON. Conversely, when JSON was designed, YAML did not exist, so it only became a subset of YAML when the latter was introduced.

Re: Fear and Loathing in YAML

#86

Post by baq »

cferr wrote: post #27
baq wrote: post #8

I’d say yaml itself is the smaller part of the problem. The real fun starts when its obvious shortcomings (for use cases it’s being attempted to fulfill) are being papered over with jinja2, code in nondescript languages embedded in string values and css-like composition rules for multiple files.

You mean like with Ansible?

i tried really hard to not call any names... :)

Re: Fear and Loathing in YAML

#87

Post by goatinaboat »

viraptor wrote: post #70
slifin wrote: post #30

In a world where there's only a few primitive types no one can share uuids or dates across the wire without both sides knowing which fields are dates or uuids ahead of time JSON is too simple we need more primitive types and an extensible data notation to formalise data sharing of unknown types

That's one way to go, but there are other options. You want inline annotation of types. On the other side you can have an external jsonschema which provides the same information. Realistically, you can't do "data sharing of unknown types" - at that point you're just sharing binary blobs.

Realistically, you can't do "data sharing of unknown types" - at that point you're just sharing binary blobs.

ASN.1 and CORBA both let you share types that are unknown ahead of receiving.

Re: Fear and Loathing in YAML

#88

Post by wodenokoto »

colejohnson66 wrote: post #51
andybak wrote: post #42

Earlier quoted context omitted.

My keyboard shortcut for automatically formatting my documents usually understand the document format or programming language I'm using. If it doesn't then I'm using the wrong editor.

The problem is that in YAML, white space is significant. How is a formatted supposed to know: key1: value1 key2: value2 ...is supposed to be: key1: value1 key2: value2 ? How is it supposed to know if the first is actually what you meant to write? In grammars that aren’t white space dependent (such as JSON), it’s clear what this means: { "key1": "value1", "key2": "value2" }

If you write

    { "key1": "value1", "key2": "value2" }
without the commas, you're also on your own when it comes to fixing it.

You just type [enter] instead of [space] between "value1" and "key2:" in your original example to get correct indentation.

Re: Fear and Loathing in YAML

#89

Post by viraptor »

goatinaboat wrote: post #87
viraptor wrote: post #70

Earlier quoted context omitted.

That's one way to go, but there are other options. You want inline annotation of types. On the other side you can have an external jsonschema which provides the same information. Realistically, you can't do "data sharing of unknown types" - at that point you're just sharing binary blobs.

Realistically, you can't do "data sharing of unknown types" - at that point you're just sharing binary blobs. ASN.1 and CORBA both let you share types that are unknown ahead of receiving.

I don't know much corba, but in asn.1 it's basically "a field tag and a binary blob". It could be also a standard structure tagged with an unknown id, but either way I don't really see it as much more than json `{"uid": "blob-data"}` in practice. If it's unknown data, you can do almost nothing with it apart from passing it on. If I recall correctly, x509 doesn't even want to deal with any complicated tagging and embeds each extension value as a serialised DER itself.

Re: Fear and Loathing in YAML

#90

Post by rswail »

I used to like Python, but the whitespace stuff irritates me more and more. Sure, it's easy to read, but having those braces also makes code easier to read.

Maybe not opening braces, they're sorta redundant, but closing braces allow me to "pop stack" when I read them.

Yaml combines the worst of whitespace with the use of whitespace without keywords, which makes things even harder.

JSON is ok, particularly if your editor auto-quotes things, I wish it had comments, but having something that strips comments is a single sed pre-processing line.

Neither are great for human generation or consumption, but at least JSON is only trying to be a serialize/deserialize syntax and doesn't claim to be more.

YAML truly lives up to the "YA" part. It's trying to be the COBOL of configuration, able to be read and written by anyone. But no one needs that.

Post reply on HN