Hacker News Reader

Comment by xg15 | Hacker News Reader

JSON5 allows comments.

Can someone explain to me what is so horrible about curly braces that we need a whole host of "human-friendly" configuration languages with nontrivial parsing just to get around them?

View on HN

    s/JSON/YAML/g
    s/curly braces/whitespace/g

Well in that case, it's all the ways that IDEs like to jank up whitespace, as well as the additional difficulty knowing 'context'.

With JSON it's fairly easy for me to know if I want to end my structure as well as the structure containing it, I can just type }}, and add the next element.

With whitespace you have to keep track of HOW MUCH whitespace, and trust me once you've got people who are entirely inconsistent with how much whitespace they use it becomes a huge PITA.

My point was the arguments are much the same for any human edited, computer parsed format. As for whitespace, you can set many IDEs to display placeholder markers if you want to go that route, it does help with visualizing horizontal alignment.

I find that paste/format on copy/paste with YAML can be kind of troublesome too though... I have an exception in my vscode settings file for that format, my default is format on paste and save.

We are stuck in the old paradigm of characters taking space on the screen and the idea that a markup language must support classic dumb TUI. If, just imagine it, we used some Unicode range for control characters for the semantic markup and standardized UX for it, we wouldn’t need using normal characters as delimiters and escaping them in strings.

The following would have parseable structure, but would be free of visual noise.

  Title: Markup languages: decades of going in the wrong direction 
  Keywords: hypertext,
      delimiters, 
            ˋ, ", \

People have suggested using the control characters for CSV structured files. The problem is that they are impossible to edit.

Control characters are invisible, using them means changing text editors to display them. They are also, outside the usual ones, hard to type. ASCII ones have Ctrl combos, but editors used those for other things.

Also, what is the difference between using some new character to start block and "{" or "\n"? Why have new thing to indicate new level when have space and tab?

> Control characters are invisible, using them means changing text editors to display them. They are also, outside the usual ones, hard to type. ASCII ones have Ctrl combos, but editors used those for other things.

Yes. Change of paradigm does require change of tooling. If some legacy tool doesn’t support new format, it’s not a good reason not to use new technology - either tool evolves or a replacement emerges and typing won’t be a problem. Classic formatting commands from rich text (Ctrl-B etc) can be repurposed, for example.

>Also, what is the difference between using some new character to start block and "{" or "\n"?

Any such delimiter has other use in text. Dual use means extra ceremony with escaping and extra complexity. Whitespace as a delimiter has especially bad UX, because most editors don’t understand the semantics and it is very to make mistakes.

> Dual use means extra ceremony with escaping

It depends, if you allow nesting you also need escaping.

Escaping of what?

Of 'yourself', if a text field contain embedded/nested text you need to escape the delimiter.

This case is much rarer than escaping quotes or whitespace. It will happen only if the content of the block will contain unsanitized inputs. In such case a control character for escaping will help, or, if you can have 2x range for control characters, you can use one bit for escaping. E.g. 0x1-0x7 - delimiters, 0x8-0xF - escaped delimiters.

ASCII has 4 delimiter characters: file, group, record, and unit.

They are not used in editors that I have ever seen.

They are theoretically accessible as ctrl-/, ctrl-], ctrl-^, ctrl_

Editors absolutely should be able to show them using syntax highlighting.

There are 3 more: 001, 002 and 003

Probably most of the first 32 can be repurposed.

Markup languages should support TUI / plain terminal, because many people still use that as their IDE. If I can’t pipe a file around to standard *nix tooling, it’s not a good format.

You can pipe a file with unicode control characters. If your terminal supports Unicode (it must), it can even display those control characters (e.g. as small curly braces) or choose another form of presenting the text. Markup languages do not have to support every legacy terminal - all new tech requires users to upgrade at some point.

Don't ask me, I don't even know what was so bad about XML tags.

Probably the verbosity, necessity of a schema for typing, and mixing of text with tags as siblings.

And having to add both opening and closing tags.

Yes, that's a large part of the verbosity I was mentioning.

This should be perfectly valid:

< date="today" id="978"/>

I could have used this many times.

Not fashionable enough. In all seriousness XML is so much more powerful and no need for a parser with infinite edge case. Editing is just fine with the proper editor/IDE. But there is a religion around plaint text and minimal editors so whatever...

JSON 5 is pretty good. It just needs to make the top-level brace and all commas optional, and add proper support for multi-line strings (writing '/n/' at the end of every line doesn't count).

Allowing only valid JavaScript identifiers to be unescaped keys is also a bit quirky (You have to quote reserved keywords).

But they will never change any of that because it would break JavaScript compatibility.

I can see someone wanting the Markdown of markup languages: more convenient for people to read and write. Sure, without markdown you could write HTML, say. But editing Markdown is a nicer experience.

I prefer curly braces. My editor has all sorts of comments to jump between opening and closing curly braces. This is not possible with whitespace.

Honestly, nothing. Except the endless debate on where the braces go, and how long they're allowed to stay on a single line.

It seems trivial, but replacing scope delimiters with a per-line signifier (i.e. indent) makes the scope of each line self-contained and sidesteps that discussion.

Is that worth YAYAML (Yet another YAML)? I don't know. But I certainly get the desire to skip the discussion :)

But it can't be minified without keeping the line endings and whitespace, unlike JSON.

You don't need to convince me. The question was "why would people want this", not "why are they wrong to want it" :)

Reply on news.ycombinator.com