personally i don't like dangling commas.
A modest proposal
81–90 of 189 posts
Re: A modest proposal
#82Earlier quoted context omitted.
In Rust, omitting the last semicolon in a block indicates an implicit return of the final expression of the block.
That's terrible, to have semantics depend on such a tiny syntax change that's so easy to miss.
Don't sweat it, your compiler will point it out and it's fairly ingrained to functional programmers that the last line of function is its return value anyway
Re: A modest proposal
#83Yes, please! This applies to many other lists as well, not only restricted to JSON. Besides, imagine a world of Java, Javascript, C-like anything, where you would be DISALLOWED to have a semicolon after the last statement in a block. Crazy thought, right?
In C you couldn't follow cases and labels with just a semicolon, it was an invalid statement. That's because a statement couldn't be just a semicolon. But yes, I agree.
[deleted]
Re: A modest proposal
#84Earlier quoted context omitted.
In Rust, omitting the last semicolon in a block indicates an implicit return of the final expression of the block.
That's terrible, to have semantics depend on such a tiny syntax change that's so easy to miss.
By your logic, you should also hate the "+" and "-" operators – they're just as easy to confuse as ";" and "", completely change the semantics, and the type checker won't even catch your mistake!
Re: A modest proposal
#85Earlier quoted context omitted.
I wish there was times that HN supported Quadratic Voting[0] so that I could more (but costly) up votes to a really sane and pertinent comment. [0] http://ericposner.com/quadratic-voting/
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 and walk away, rather than spend it on voting.
If the ballot measure is "Eat Vinnl", you might want to spend a lot to vote it down, but it might not take much to convince the others not to spend it back at you (and you all eat berries instead). If the ballot measure is "Vinnl eats everyone else", you won't be able to spend enough that everyone else can't just spend it back at you, more efficiently.
Edit: one important difference here is that unless the GP is actually going to pony up real money, something of value to those they inconvenience with their (imo silly) opinion, it doesn't make much sense.
Re: A modest proposal
#86Good ol' S-expressions! I'll gladly stick with some extra parentheses (which can be easily made readable with consistently applied indentation) instead of these problems with commas and other rigid syntax issues.
Re: A modest proposal
#87Earlier quoted context omitted.
There is a damned good reason JSON does not allow comments. It's not an accident.
So can you fill the rest of us in on the reason then?
They tend not to survive roundtripping well, for example. JSON describes data; comments are metadata. To do them well you'd have to bring them into JSON infoset, such as it is.
(ETA: JSON already has problems with canonicalization. Adding comments makes this worse. Are they in or out of the equivalence over JSON terms?)
Re: A modest proposal
#88I'm surprised this got voted up considering how dismissive (and, frankly, mean) HN was to "JSON5" a few years back https://news.ycombinator.com/item?id=4031699 Trailing commas have been fine everywhere in JS since IE7 - it's about time all interpreters have this as an option, and preferably on by default.
Anyone looking for a “better JSON” night was well just move to YAML. Someone managed to make JSON5 the config format for something here and we wasted way too long before switching that over to YAML. Now we have a bunch of JSON5 with comments we’ve gotta manually transcribe.
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...
Re: A modest proposal
#89personally i don't like dangling commas.
Me neither but it should be tolerated.
Re: A modest proposal
#90Earlier quoted context omitted.
Haskell makes a reasonable job of combining infix operators with no commas between function arguments[1]. You sometimes end up with a few extra parentheses and $s instead, but things generally seem to work out. Does use commas for lists and tuples, though. The latter kind-of make sense, it's the commas that identify the expression as a tuple. Not sure what the rationale for commas in lists is, though. [1] Slightly co…
> Not sure what the rationale for commas in lists is, though. Well, you need some separator, and spaces won't do since [x y] has x applied to y.
Good point.
Although could, in principle, make space-between-list-items higher precedence than function application. E.g.:
[x (func y) z]