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

61–70 of 189 posts

Re: A modest proposal

#61

Post by TheSpiceIsLife »

tankenmate wrote: post #35
tomp wrote: post #29

Earlier quoted context omitted.

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/

Thanks for the link, I started reading the paper. I love this:

Groups frequently make collective decisions through majority rule. Legislators pass bills by majority; shareholders make most corporate decisions by (share-weighted) majority rule, as do directors; clubs, university faculties, and civic associations typically use majority rule as well. The reason that they do so is not entirely clear. (Emphasis mine).

Re: A modest proposal

#62

Post by unkown-unknowns »

tankenmate wrote: post #35
tomp wrote: post #29

Earlier quoted context omitted.

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/

Have you tried writing Rust? I have and I think this feature is great.

I upvoted you for your link, but actually the argument that it would be good because people who care more will make a better decision than those who don't does not completely convince me. Someone could care a lot about something but still have the wrong idea about it.

Re: A modest proposal

#63

Post by Houshalter »

sillysaurus3 wrote: post #25
sjrd wrote: 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.

It's not infix math that's the problem, it's the ambiguity of "-". It can take two arguments in one context, or one in another (or just be a representation of a negative number without implying any function call at all.) If we just used a different symbol for subtraction, it would clear up a number of other parsing problems languages run into. Or you could just require negations to be done inside parentheses.

Re: A modest proposal

#64

Post by sneak »

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.

Re: A modest proposal

#65

Post by tempestn »

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.

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

Re: A modest proposal

#66

Post by Houshalter »

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

Or you could serialise like this: { 'fields': ['a', 'b'], 'values': [ [1, 2], [5, true] ] }

I might be misunderstanding something here, why not just:

    {
      a: [1, 2],
      b: [5, true],
    }
But this doesn't solve the problem if your data isn't a nice table and has deeply nested tree structures. Which is what JSON is for, otherwise people would have just stuck with CSV.

Re: A modest proposal

#67

Post by jstimpfle »

Slightly related: I did some work on a format with really homogenous and canonical syntax that is also low-noise and human-editable. It's based on a relational representation, so also supports some integrity checks out of the box.

I also experimented with specification of transformations to/from hierarchical representations, but I think the problem is that there are different possible approaches with their own pros and cons.

http://jstimpfle.de/projects/wsl/main.html

http://jstimpfle.de/projects/python-wsl/main.html

Tell me what you think!

Re: A modest proposal

#68

Post by drodgers »

captainmuon wrote: post #45

When I use JSON, I usually make sure that the parser supports trailing commas and comments, even if I have to add that myself. The reason is that I deal a lot with machine-generated but potentially user-edited JSON. Anything else is needlessly masochistic. When producing JSON for others, I just use the minimal consensus format (read: the "official" spec).

I do the same, but instead of switching/patching the JSON parser, I replace it with a YAML one. YAML was designed to be a superset of JSON precisely so that it could be used as an upgrade path. It also allows comments and neat multiline string formatting (in addition to trailing commas).

Re: A modest proposal

#69

Post by Al-Khwarizmi »

flashman wrote: post #37
Orangeair wrote: post #5

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.

Well, the subtitle is "Let Me Put a Fucking Comma There, Goddamnit, JSON", and the argumentation is "for the love of all that is fucking holy", so I'd say the intention of the author of the proposal was not to make it look serious.

Re: A modest proposal

#70

Post by crdoconnor »

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.

Post reply on HN