Live data from Hacker News

A modest proposal

happyassassin.net

31–40 of 189 posts

Re: A modest proposal

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

Or you could serialise like this:

    {
      'fields': ['a', 'b'],
      'values': [
         [1, 2],
         [5, true]
      ]
    }

Re: A modest proposal

#32

The title is a possible reference to this satirical essay about solving poverty through cannibalism: https://en.wikipedia.org/wiki/A_Modest_Proposal

I assume so too, and it's well worth reading. From 1729, by Jonathan Swift. Full text here: http://www.gutenberg.org/files/1080/1080-h/1080-h.htm

When I was a kid in the 80s, the parents of a kid in my older brother's class complained angrily to the school about this, clearly having failed to realise it was satire.

Here's an excerpt:

"I have been assured by a very knowing American of my acquaintance in London, that a young healthy child well nursed, is, at a year old, a most delicious nourishing and wholesome food, whether stewed, roasted, baked, or boiled; and I make no doubt that it will equally serve in a fricasie, or a ragoust."

Re: A modest proposal

#33
post #22

Earlier quoted context omitted.

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.

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 complicated by currying (arguably, it's several successive function applications rather than one multi-arg application) but the end result is the same...

Re: A modest proposal

#35
post #29
post #13

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

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/

Re: A modest proposal

#37

The title is a possible reference to this satirical essay about solving poverty through cannibalism: https://en.wikipedia.org/wiki/A_Modest_Proposal

That's the problem with using "a modest proposal" for serious suggestions: you're supposed to use it for satire.

Re: A modest proposal

#38

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

Re: A modest proposal

#39

Actually, in the JSON grammar as many others, the comma is completely irrelevant for the purposes of disambiguation. Commas could essentially be treated as whitespace and nothing would substantially change. Now, I don't know whether commas allow for faster parsers in some way, but edn[1] seems to be doing just fine without them. Once you get used to optional commas, it really becomes a nuisance having to type them, e…

> Actually, in the JSON grammar as many others, the comma is completely irrelevant for the purposes of disambiguation. Commas could essentially be treated as whitespace and nothing would substantially change.

A while ago I saw somebody who had implemented pretty much that: a streaming non-validating JSON parser which just ignored commas and colons entirely.

Re: A modest proposal

#40
post #29
post #13

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

In practice it's not so bad, because your program won't compile if you've missed returning something in any branch, or if you've returned the wrong thing.
Post reply on HN