Complainers in this thread might take a look at YAML
but "All I know is a hammer and it won't let me work this screw!"
A modest proposal
101–110 of 189 posts
Re: A modest proposal
#102Yes, 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 Erlang, commas and semicolons are separators not terminators . So you are in fact disallowed to have a semicolon at the end of a sequence of clauses, it's either nothing (for case) or a period (for functions)
It sounds dumb, but this was actually one of the things that turned me off Erlang despite my interest.
Re: A modest proposal
#103Earlier quoted context omitted.
There is a damned good reason JSON does not allow comments. It's not an accident.
gotta love the hn community, downvoting things that are correct but hurt them feels
no, we downvote things that state an opinion as fact without even an attempt at explaining why, especially when done in a tone that is aggressive and disrespectful.
Re: A modest proposal
#104Earlier quoted context omitted.
gotta love the hn community, downvoting things that are correct but hurt them feels
no, we downvote things that state an opinion as fact without even an attempt at explaining why, especially when done in a tone that is aggressive and disrespectful.
It's not an opinion however. JSON is a standard. Kinda worries me professionals use it without having a clue.
Re: A modest proposal
#105Earlier quoted context omitted.
Commas are unnecessary. There is zero benefit to having them. The code is actually easier to parse if you just remove them from the rules list entirely. No commas might look weird for a day or so, but you quickly get used to it. (I'm ignoring the comma operator, which is a special case and not relevant to the main point.)
foo(x, -y) is not the same as foo(x -y) (from your last sentence, I assume you were talking about JS in general, not just JSON)
I like OCaml's terse syntax. You can write something like that as just "foo x (-y)" (the brackets are only needed because of the use of minus but can usually be omitted).
Re: A modest proposal
#106Earlier 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…
I think he wanted it to be something different than js, hence the focus on strictly data exchange.
Why not use js for config instead of json? It's your app and your config so if you want it to look like json + comments + trailing comma you can. With so many options for config files like yaml, xml, heck even sqlite it does seem a bit silly how much json is used. Herd mentality.
Re: A modest proposal
#107Earlier quoted context omitted.
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
Oh definitely, implicit returns are awesome. I just commented on the fact that a semicolon supresses them.
Re: A modest proposal
#108Seeing 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…
> Seeing as the vast majority of statements while coding aren't multiline, I wish there was a symbol to indicate that I dunno, that kind of exists in some bash/scripting contexts (using a backslash) and I've never enjoyed it.
Bash has horrific syntax but a huge amount of coding time is wasted because of unbalanced brackets/braces and forgotten end of line statements that result in unhelpful and confusing error messages so I like things that reduce this. Bash also has the quirk where variable assignments are of the form "var=1" but their usage is "$var" which always trips me up. I just like syntax that is easy to get right first time and is copy/paste friendly.
Re: A modest proposal
#109Earlier quoted context omitted.
That's the problem with using "a modest proposal" for serious suggestions: you're supposed to use it for satire.
Wait, so is the op actually suggesting we be able to use commas? I thought op meant to say people who want to use commas are exactly like people who want to eat human babies to solve the problem of child poverty.
The second one. I read this as the author making fun of people who act like not having trailing commas is a situation so dire we may have to eat children.
Re: A modest proposal
#110Between 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.
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.