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

21–30 of 189 posts

Re: A modest proposal

#21

Post by einrealist »

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.

Why do you treat data representaions as mutual exclusive? Most web frameworks allow to have them. 'Accept: application/json, application/protobuf, text/xml'... problem solved.

Re: A modest proposal

#22

Post by sjrd »

sillysaurus3 wrote: post #11
megapatch wrote: post #2

Yes, 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?

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)

Re: A modest proposal

#24

Post by [deleted] »

mjevans wrote: post #20
sillysaurus3 wrote: post #11

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

They exist because of string concatenation. In some languages any consecutive strings are implicitly concatenated so that you can have a very long string split across many lines.

[deleted]

Re: A modest proposal

#25

Post by sillysaurus3 »

sjrd wrote: post #22
sillysaurus3 wrote: post #11

Earlier 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)

Mm, fair point. Infix math rears its ugly head again. I've been living in Lisp a bit too long.

Never mind.

Actually, let's double down: Instead of writing 1+2, you should really be writing +(1 2). Don't you see how much easier that would make things? A single, uniform syntax everywhere! + is just a function that gets called like anything else! Your foo(x -y) example would become foo(x -(y)).

I'm mostly joking.

Re: A modest proposal

#26

Post by DelTaco »

kijin wrote: post #6
megapatch wrote: post #2

Yes, 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?

Javascript: automatically inserts semicolons for you at the end of a line, but doesn't allow commas at the end of a list.

JavaScript does allow commas at the end of a list! :)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: A modest proposal

#27

Post by darawk »

quicklime wrote: post #19
megapatch wrote: post #2

Yes, 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?

Some JavaScript style standards require no semicolons at the end of lines: https://standardjs.com/rules.html#semicolons

Yes, but he means no semicolon only on the last statement of a function, I believe.

Re: A modest proposal

#28

Post by kakarot »

quicklime wrote: post #19
megapatch wrote: post #2

Yes, 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?

Some JavaScript style standards require no semicolons at the end of lines: https://standardjs.com/rules.html#semicolons

I made the switch earlier this year and I don't think I would ever willingly go back. It just looks so much more parsable. Semicolons at the end of my statements just look ugly and savage now.

Re: A modest proposal

#29

Post by tomp »

emmab wrote: post #13
megapatch wrote: post #2

Yes, 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 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.
Post reply on HN