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

YAML: Probably not so great after all

arp242.net

Post reply on HN
Print view View original

181–190 of 457 posts

Re: YAML: Probably not so great after all

#181

Post by jchw »

The issue is, I think most people (myself included) enter YAML into their lives as basically a JSON alternative with lighter syntax. Without really realizing, or perhaps without internalizing, the rather ridiculous number of different ways to represent the same thing, the painful subtle syntax differences that lead to entirely different representations, the sometimes difficult to believe number of features that the language has that are seldom used..

It's not just alternate skin for JSON, and yet that's what most people use it for. Some users also want things like map keys that aren't strings, which is actually pretty useful.

I recall there being CoffeeScript Object Notation as well... perhaps that would've been better for many use cases, all things said.

Re: YAML: Probably not so great after all

#182

Post by dagenix »

markmark wrote: post #160
crazygringo wrote: post #23

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

I say just use JSON. Everyone knows it already and it's good enough. Use a parser in your app that allows comments and trailing commas like vscode does.

That's not JSON anymore, that's some custom format that's JSON inspired.

Re: YAML: Probably not so great after all

#183

Post by jokoon »

I liked the indented style of YAML, asked how to properly parse an indented file, and wrote my own small "parser".

What's nice about YAML is the choice to use indentation, for the rest, I have a hard time following the language's choices.

Re: YAML: Probably not so great after all

#184

Post by twic »

KaoruAoiShiho wrote: post #141
beders wrote: post #118

Earlier quoted context omitted.

do you deliver a YAML editor with your software? Because people will use notepad or nano to edit that stuff.

Sort of, I deliver a GUI that exports into YAML for pretty much only reading, portability, and version control. People are expected to do the editing in the GUI, only using YAML for editing when doing complex regex operations that my GUI doesn't support.

If people aren't editing it by hand, why does the format matter? Why not just use JSON? Tools for too-complex-for-the-GUI manipulations are at least as good for JSON as they are for YAML, and the editing is less error-prone.

Re: YAML: Probably not so great after all

#185

Post by kevin_thibedeau »

ridiculous_fish wrote: post #96

fish shell is looking for a new text serialization format for its history file (currently it uses an ad-hoc broken psuedo-YAML). Boxes to check: 1. Self describing format 2. SAX-style parser available to C++ 3. Easy for users to understand and ad-hoc parse using command-line tools 4. No document closing necessary, so appending is trivial YAML looks pretty good: - cmd: git checkout file.txt when: 1565133286 pwd: /home…

Tcl with control structure commands disabled and infix assignment for convenience. Jim Tcl is a lightweight implementation if the main line isn't workable.

Re: YAML: Probably not so great after all

#186

Post by throwaway_391 »

thayne wrote: post #132
cryptica wrote: post #121

I never understood how YAML is more human-readable than JSON. I find JSON much easier to read. What annoys me the most about YAML is that it's easy to misinterpret the indentation. You need a special IDE to know whether a property belongs to a specific object or to its parent.

> I never understood how YAML is more human-readable than JSON Two things: comments and multi-line strings.

My personal JSON Pet hate is: ``` x = [ "Foo", "Foo2", ] ``` Is not valid, but the following is: ``` x = [ "Foo", "Foo2" ] ``` Makes dealing with packer configs feel like punching yourself in the face.

I still prefer it over YAMLs awkward initial learning curve.

Re: YAML: Probably not so great after all

#187

Post by [deleted] »

markmark wrote: post #160
crazygringo wrote: post #23

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

I say just use JSON. Everyone knows it already and it's good enough. Use a parser in your app that allows comments and trailing commas like vscode does.

[deleted]

Re: YAML: Probably not so great after all

#188

Post by twic »

mcphage wrote: post #73
crazygringo wrote: post #23

So what's the HN consensus on the best format for config files? Is it TOML as the author seems to prefer at the end?

In the scale world, HOCON is very nice. It’s a format designed explicitly for config files, and has a lot of niceties (like you can append files together and they merge correctly, so you don’t have to end up with giant config files)

What's the "scale" world?

Re: YAML: Probably not so great after all

#189

Post by PaulHoule »

reilly3000 wrote: post #176

Kubernetes supports JSON but overwhelmingly leans towards YAML. I've had to spend some time really grokking it to do basic dev ops, and now have my IDE pretty dialed to support it. That said, its not my favorite by a long shot. Can Jsonette save us?

JSON is valid YAML.

Re: YAML: Probably not so great after all

#190

Post by userbinator »

whatshisface wrote: post #172
booleandilemma wrote: post #166

Earlier quoted context omitted.

Giving meaning to whitespace causes so many headaches and yet people still embrace Python, for some reason. I don’t understand it.

Your editor makes a world of difference here. Since you shouldn't be writing brace-language code without indents anyways, the biggest issue remaining is mixing tabs and spaces. Gedit makes this a big pain with it's default config (it doesn't even auto-indent) but Atom and IDLE handle it well.

Code you write yourself is not usually the source of problems with significant whitespace; it's situations like posting code on websites and discussing it where code in a whitespace-significant language becomes next-to-useless when leading whitespace is stripped, whereas code in any other language will still survive and then easily be autoformatted without changing its meaning.
Post reply on HN