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

A modest proposal

happyassassin.net

Post reply on HN
Print view View original

141–150 of 189 posts

Re: A modest proposal

#141

Post by coldtea »

echelon wrote: post #4

I really dislike JSON. It's better than XML, but not by much. There are several fundamental problems with JSON, one of which being that you have to duplicate the field names over and over again. It's just not a very structured format. Trailing commas is the least of my concerns. I would like to see protobuf take over at this point.

>I really dislike JSON. It's better than XML, but not by much.

You'd be surprised -- if you had to live through the XML madness of the early 00s. And don't get me started on SOAP, XML namespaces and other crap.

>There are several fundamental problems with JSON, one of which being that you have to duplicate the field names over and over again.

You don't duplicate field names. You define different objects that just happen to have the same fields. They could just as well have different ones.

That's something for transport compression to handle.

Re: A modest proposal

#142

Post by NateDad »

crdoconnor wrote: post #127
sametmax wrote: post #92

Earlier quoted context omitted.

Yeah json is a fact of life, the fact yaml exists doesn't change that. Actually, toml is even better than yaml and yet...

TOML's array/table syntax is kind of confusing, especially when you're a few levels deep. Having meaningful whitespace in YAML makes it clearer. It's also kind of messy when you have a lot of multiline strings.

Meaningful whitespace is horrid. I speak from 3.5 years of working on s project that exclusively used yaml as configuration. Yaml is horrid.

Toml is way better. Yes, multilayered objects in toml are ugly. Don't make your users created multilayered objects for their configuration. That's just a bad UX regardless of the language.

Re: A modest proposal

#143

Post by keymone »

ComputerGuru wrote: post #115
keymone wrote: post #81

personally i don't like dangling commas.

They’re version control friendly.

They are visually annoying and I'll trade that for minor visual annoyance while looking at diffs any day. I look at code far more often than I look at diffs.

On a related note I'd rather not have any commas like in EDN. All problems go away.

Re: A modest proposal

#144

Post by NateDad »

callumlocke wrote: post #119
mschuster91 wrote: post #110

Earlier quoted context omitted.

YAML can go off and die in a fire... especially because it cannot transfer the data type, which JSON can: you have either an integer, a float or a string. Also some libraries want the values escaped, some not, some barf on non-alphanumeric keys... JSON is pretty much standardized across the board.

I use YAML all the time (for config) and the things you mention have caused no more than one minute's frustration in my life. JSON is great for serialisation, YAML for little config files that need frequent hand-editing during development.

Yaml is terrible. The fact that there are so many optional and different ways to format things and the fact that it has significant white space means it's horrible to hand edit. I'd much rather hand edit json. At least it won't care if I accidentally use a tab instead of two spaces.

But of course toml is superior to both because it has comments and no significant white space and the comma at the end of lists is optional.

Re: A modest proposal

#145

Post by coldtea »

seanwilson wrote: post #91

Seeing as the vast majority of statements while coding aren't multiline, I wish there was a symbol to indicate that instead of a symbol to represent the end of a single line statement. I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces. Going further with this, I wish languages would be more copy/paste friendly. For exa…

>I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces.

You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc).

And because of allowing to mix tabs and spaces, you also get other issues.

I think go had the best idea in this with gofmt: all code should be auto-formatted absolutely the same -- then it becomes trivial to read.

Re: A modest proposal

#146

Post by coldtea »

demircancelebi wrote: post #51

Complainers in this thread might take a look at YAML

People suggesting YAML might want to think long and hard about its horrible syntax issues, and why it didn't make it as the de facto serialization/config format as much as JSON did.

Re: A modest proposal

#147

Post by coldtea »

keymone wrote: post #143
ComputerGuru wrote: post #115

Earlier quoted context omitted.

They’re version control friendly.

They are visually annoying and I'll trade that for minor visual annoyance while looking at diffs any day. I look at code far more often than I look at diffs. On a related note I'd rather not have any commas like in EDN. All problems go away.

>They are visually annoying

That's a personal opinion -- like a mild OCD annoyance, etc, most like borne just out of being used to not having them from the start.

Their benefits on the other hand (uniform syntax, easier insertions/deletions, better for source code control, etc) are objective.

And there's no objective visual annoyance when looking at the code to see that it's uniformly comma-ed.

Re: A modest proposal

#148

Post by NateDad »

callumlocke wrote: post #123
donatj wrote: post #88

Earlier quoted context omitted.

Every YAML parser I've ever used has been literal magnitudes slower than the slowest JSON parser. It's way too flexible a format. > YAML may seem ‘simple’ and ‘obvious’ at a glance, but it’s actually not. The YAML spec is 23,449 words; for comparison, TOML is 838 words, JSON is 1,969 words, and XML is 20,603 words. https://arp242.net/weblog/yaml_probably_not_so_great_after_a...

If data is so big that parsing is a bottleneck, that seems like the wrong case for YAML. It's good for hand-edited and human-readable config files, and it's fast enough for that.

Toml is far superior for hand editing. This is why yaml is terrible (aside from significant white space):

    foo: 80:80
    bar: 22:22
    baz: 22.22
What's the value of foo? It's the string "80:80". What's the value of baz? The float 22.22 What's the value of bar? The integer 1342.

I rest my case about both readability and writability.

Re: A modest proposal

#149

Post by yorwba »

seanwilson wrote: post #91

Seeing as the vast majority of statements while coding aren't multiline, I wish there was a symbol to indicate that instead of a symbol to represent the end of a single line statement. I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces. Going further with this, I wish languages would be more copy/paste friendly. For exa…

I vaguely recall some PL research that used the dot as a scoping operator, you could write object.(expression) and all fields of the object were automatically in scope within the expression. Your example would look like

    a.(
      x = 1;
      y = 2;
    )
Post reply on HN