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

151–160 of 189 posts

Re: A modest proposal

#151

Post by krapp »

crdoconnor wrote: post #70
fermigier wrote: post #41

Between commas and comments, I would personally vote for comments. JSON is, unfortunately, used in many places as a configuration language (think package.json). Sometimes you have to comment out a section for some experiment. Many times, you want to explain why you included this or that in the config. Hence comments. The trailing commas issue is slightly annoying, but an order of magnitude less important IMHO.

It may be used as such but it shouldn't be. YAML serves this purpose much better. JSON works better as a language independent serialization format that is incidentally readable.

Lua tables are better than both, in my opinion. Simpler than JSON, allows for comments, and whitespace is not syntactically significant.

Re: A modest proposal

#152

Post by krapp »

sneak wrote: post #64
fermigier wrote: post #41

Between commas and comments, I would personally vote for comments. JSON is, unfortunately, used in many places as a configuration language (think package.json). Sometimes you have to comment out a section for some experiment. Many times, you want to explain why you included this or that in the config. Hence comments. The trailing commas issue is slightly annoying, but an order of magnitude less important IMHO.

There is a damned good reason JSON does not allow comments. It's not an accident.

Not liking comment macros is not a "damned good reason," it's just a reason. People could still do that in JSON anyway the same way they hack in comments - just add them as strings.

Re: A modest proposal

#153

Post by nly »

mschuster91 wrote: post #110
crdoconnor wrote: post #70

Earlier quoted context omitted.

It may be used as such but it shouldn't be. YAML serves this purpose much better. JSON works better as a language independent serialization format that is incidentally readable.

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.

> you have either an integer, a float or a string.

JSON doesn't have "integers" and "floats", it has "numbers" which are are expressed in decimal scientific notation. There's no guarantee an implementation will let you distinguish what was parsed, and the numerical precision and range of interoperable JSON is undefined.

The bottom line is JSON is a risky proposition for financial or scientific data exchange.

And before you say JSON numbers are de-facto IEEE754 doubles, bare in mind that most JSON implementations can't roundtrip them properly.[0] A symptom of everybody wanting to write a toy implementation.

[0] https://rawgit.com/miloyip/nativejson-benchmark/master/sampl...

Re: A modest proposal

#154

Post by callumlocke »

guipsp wrote: post #131
callumlocke wrote: post #123

Earlier quoted context omitted.

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.

Hand-edited and human-readable? With significant whitespace and tab-space difference?

Human readability is exactly the point of significant whitespace. And I'm not sure how significant whitespace could even work without distinguishing between tabs and spaces, as a tab could represent any number of spaces.

Re: A modest proposal

#155

Post by keymone »

coldtea wrote: post #147
keymone wrote: post #143

Earlier quoted context omitted.

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.

> personal opinion

I take it you didn't read my original comment?

Also I disagree, dangling comma is a visual cue that the sequence has a continuation.

Re: A modest proposal

#156

Post by nly »

peterbraden wrote: post #7
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.

It's an unstructured format, that's the point. You can't edit a protobufs in an editor.

Proto3 has a JSON serialization that you can use as an intermediate for editing

Re: A modest proposal

#157

Post by coldtea »

keymone wrote: post #155
coldtea wrote: post #147

Earlier quoted context omitted.

> 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.

> personal opinion I take it you didn't read my original comment? Also I disagree, dangling comma is a visual cue that the sequence has a continuation.

>Also I disagree, dangling comma is a visual cue that the sequence has a continuation

We already have a mechanism for telling whether a sequence ends or not -- the opening and closing bracket for the sequence. No need to have a second redundant one.

This way the last element is an ordinary part of the sequence as any other and doesn't need a special exception to its formatting like the omission of the comma.

Besides the point is moot as the "dangling" comma is already part of the JS standard.

Re: A modest proposal

#158

Post by guitarbill »

NateDad wrote: post #142
crdoconnor wrote: post #127

Earlier quoted context omitted.

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.

> Meaningful whitespace is horrid

Millions of Python programmers might disagree, not to mention that most programmers using languages with meaningless whitespace (as far as the computer is concerned) still put whitespace in there, because humans.

And it isn't like INI is a great experience, either. Flat configs suck in their own ways.

Re: A modest proposal

#159

Post by guitarbill »

rootlocus wrote: post #74
tempestn wrote: post #65

Earlier quoted context omitted.

So can you fill the rest of us in on the reason then?

You can blame Crockford for that: [1] TLDR: Basically, in a typical Crockford move, he saw people were using them in a specific way he did not like (to store parsing parameters), so he removed them entirely. I say "typical Crockford" because some of his JS linting rules are gratuitous overkill in my opinion. He also suggests that if you want comments, you should pipe the config file through a minifier that removes th…

Comments also are a bit tricky to preserve when programatically modifying data structures, so a destructive minifier approach makes sense. Although it's very Javascript, "let's make another utility you now need".

Crockford probably didn't think it would take off like it did, but with hindsight comments would have been the pragmatic choice IMO.

Re: A modest proposal

#160

Post by Vinnl »

frankmcsherry wrote: post #85
Vinnl wrote: post #71

Earlier quoted context omitted.

Since we're going off-topic about QV here: am I correct in my understanding that you can _buy_ votes there? Because the obvious problem (because I'm probably missing something) with that would be that money is not as costly for some as it is for others? In other words, it'd lead to tyranny of the wealthy?

(from a cursory read) You can buy votes, but they become increasingly costly. Also, the payments are redistributed out among the population, so if you spend 1B to buy 31.6K votes, that 1B gets handed to the population at large who, if larger in number, can more efficiently re-spend it voting you down. What I imagine QV does is find the point at which participants who don't care so much would rather pocket the funds a…

So it's a method of exchanging influence for money for poor people, and money for influence for rich people? Still doesn't sound that great...

Anyway, I see it's been submitted separately :) https://news.ycombinator.com/item?id=15206291

Post reply on HN