Comment by drawkbox | Hacker News Reader

Comment by drawkbox | Hacker News Reader

JSON really shouldn't change at all that is why it is so great, basic types and very simple and clean. We should build a fortified defense around JSON and keeping it the same.

Of course there is no problem making a new standard, mongo did that with BSON. It is different and should be called different, nothing wrong with abstractions.

The reason we all love JSON is that it has stayed the same. Develop a coffescript like JSON precompiler with comments and trailing commas and all sorts of things like no quoted keys if needed but call it something different. I think the last thing anyone wants to do it shake the JSON standard or have to have multiple parsers try for all the new JSON formats/schemas/namespaces/etc like an XML SOAP nightmare.

EDIT: Ok so it does have compiling to regular JSON but just not a fan of the name.

This file is written in JSON5 syntax, naturally, but npm needs a regular JSON file, so compile via `npm run build`. Be sure to keep both in sync!

> Develop a coffescript like JSON precompiler with comments and trailing commas and all sorts of things like no quoted keys if needed but call it something different.

Someone did, it's called yaml.

And I still don't understand why you'd pick yaml over anything else out there.

I pick it for config files humans have to write and read because writing and reading json as a human is tedious and error prone.

As someone who has to write yaml... writing yaml is significantly more error-prone than JSON. It has far more edge cases than JSON does.

I agree it has a lot of corner cases, but they are mostly in service of allowing for an uncluttered document. The fact that you can always write a subset of the document in json is helpful when things get hairy.

But this is a thing that often gets ignored when talking about what humans are good at reading and writing. We aren't computers (or at least, we aren't as linear of computers). It's obvious enough in the languages that we speak and write every day with each other that we derive from and plant a lot of meaning in the margins of our expression. We tend to understand things quite clearly when noise has been elided out. A lot of JSON becomes pure noise: "{{[[{[{{[".

Really, though, what I'm most in favour of is that now that we've agreed on a basic data model that is less insane than its obvious predecessors (ASN.1 and XML) it would be nice if applications with configuration opened themselves to allowing the user to decide the specific format for their own benefit. If it's TOML or JSON or JSON5 or JSON+comments (Sublime Text) or YAML or whatever, so long as it results in the same structure who cares?

> A lot of JSON becomes pure noise: "{{[[{[{{[".

I'd rather that be visible brackets than invisible whitespace.

Why?

Assuming 'invisible whitespace' in this context is actually a meaningful thing. I find it hard to miss indentation, if anything, to the point that given a conflict between whitespace and a sea of brackets/braces my first instinct is probably to trust the whitespace. I don't think I'm alone in that.

so do you use tabs or spaces. or tabs AND spaces. Is that 2 spaces or 4? or did I accidentally put 5 in somewhere? is a trailing space going to cause problems or not? Text editors certainly don't help keep this stuff straight. I just don't think white space should be part of the syntax. It makes editing HARDER. not easier. And it's not even visible, unless I turn on a special feature in my text editor.

I just don't know what exactly you YAML guys are smoking that you think it's easy or more humanistic.

...

So, in YAML you can only use leading spaces. Leading tabs are an error. This confusion of yours is not at all present in the actual thing you're talking about. And if you mix them in json god help you if your editor settings don't match someone else's because you might be looking at something nearly incomprehensible that won't error or warn at all.

I mean, have you ever actually looked at a code file of any sort with mixed tabs and spaces when the person who wrote the file had a different tab stop than you? This is a readability problem no matter what. Forcing you to have sane indentation is a feature of whitespace-sensitivity, not a bug.

What exactly do you think trailing whitespace does?

If I'm smoking something, at least I've used the things I'm talking about instead of spreading weird FUD.

> at least I've used the things I'm talking about instead of spreading weird FUD.

> A lot of JSON becomes pure noise: "{{[[{[{{[".

Pro-tip: if you are going to call someone out for not knowing a format and spreading FUD, don't post things where you do the same exact thing. It pretty much invalidates the criticisms you've been making as it says "I don't know what I'm talking about, here is proof."

That'd be cute if what I said there didn't come from experience, even if I did exaggerate the specifics.

Yes, the specific sequence of tokens is not valid because a list obviously can't be a key. The idea is still the same. I'll fix it so it is a valid sequence of tokens that's just as confusing: "}}}]}]}}"

honestly that's a code smell in any data serialisation notation. if you really did have a data structure like that it would manifest in yaml as an indentation 32 space characters. If you adhere to the 78 column rule, you've squeezed most of your data to the right of almost half your screen.

Anyways, invisible syntax errors still suck. At least with json you can (eventually) figure out your braces are unbalanced. Or use a syntax highlighter to spot the problem. No syntax to highlight if you have a problem with yaml.

Or how about this:

Crazy, huh?

> I find it hard to miss indentation,

I've been having to deal with large YAML config files lately, and find it's easy to miss indentation. Even with niceties that add lines to the different indentations, it's hard to keep track of where you are. Beyond a short, simple YAML file, I find it gets confusing really fast to the point of frustration.

Is the reason for "json5" understandable?

Hierarchical, supports comments for explanation of intent, is more supported than HOCON. Data type specifiers a major plus.

I'll take all your suggestions.

Reply on news.ycombinator.com