
A modest proposal - rbanffy
https://www.happyassassin.net/2017/09/07/a-modest-proposal/
======
fermigier
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.

~~~
crdoconnor
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.

~~~
mschuster91
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.

~~~
callumlocke
I use YAML all the time (for config) and the things you mention have caused no
more than one minute's frustration in my life. JSON is great for
serialisation, YAML for little config files that need frequent hand-editing
during development.

~~~
NateDad
Yaml is terrible. The fact that there are so many optional and different ways
to format things and the fact that it has significant white space means it's
horrible to hand edit. I'd much rather hand edit json. At least it won't care
if I accidentally use a tab instead of two spaces.

But of course toml is superior to both because it has comments _and_ no
significant white space _and_ the comma at the end of lists is optional.

------
web007
I'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](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.

~~~
jitl
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.

~~~
donatj
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...](https://arp242.net/weblog/yaml_probably_not_so_great_after_all.html)

~~~
callumlocke
If data is so big that parsing is a bottleneck, that seems like the wrong case
for YAML. It's good for hand-edited and human-readable config files, and it's
fast enough for that.

~~~
NateDad
Toml is far superior for hand editing. This is why yaml is terrible (aside
from significant white space):

    
    
        foo: 80:80
        bar: 22:22
        baz: 22.22
    
    

What's the value of foo? It's the string "80:80". What's the value of baz? The
float 22.22 What's the value of bar? The integer 1342.

I rest my case about both readability and writability.

~~~
thanksgiving
> bar: 22:22

I know zero toml (don't even know what toml stands for) but I'm pretty sure
you meant the value of bar is the string 22:22 based on foo.

~~~
falcolas
I think he's attempting to point out a shortcoming of yaml; I can reproduce it
myself in Python.

That said, I've never run up against this myself - in the face of potential
ambiguity I attempt to be explicit, and surround it in quotes to be explicit
string.

TOML itself is going through its own growth pains brought on by a rather
sizable spec. For example:

    
    
        >>> pytoml.loads("foo = 20:20:20")
        [...]
        pytoml.core.TomlError: <string>(1, 9): msg

------
megapatch
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?

~~~
sillysaurus3
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.)

~~~
sjrd

        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)

~~~
sillysaurus3
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.

~~~
dasmoth
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...

~~~
tromp
> 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.

~~~
dasmoth
Good point.

Although could, in principle, make space-between-list-items higher precedence
than function application. E.g.:

    
    
        [x (func y) z]

~~~
mrkgnao
But how do you write a list with only one element, _x (func y) z_?

~~~
dasmoth
[(x (func y) z)]

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

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

~~~
thanksgiving
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.

~~~
coldtea
> _Wait, so is the op actually suggesting we be able to use commas?_

Yes, I think they do.

The author just borrowed the title of Swift's article in the sense "here's a
fun title based on a historical reference, for something that, for once, it's
indeed a modest proposal".

They didn't intend it in the exact same way Swift intended it.

------
wscott
Scanning the comments I don't see my reason for wanting trailing commas:
version control.

You want to preserve the history of your code and to be able to easily query
your VC system about the providence of each line of code. I want to add a new
item to the end of the list, I also need to add a comma to the end of the
previous line. This makes my commit larger than needed and it muddies the code
history.

Just let me make simple incremental additions to a file as it changes.

~~~
richthegeek
If that's your only concern, leading commas are a solution.

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

~~~
drodgers
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).

~~~
captainmuon
That is a good option, but YAML is too complex for my taste, with the optional
indentation based syntax. JSON + comments, like what sublime text uses for
configs, is a sweet spot for me. If you know JS or Python, you can probably
write it instinctively.

------
l0b0
This isn't the only problem with JSON as a standard by a long shot[1]. Like
Markdown and PHP its use has grown to the point where an extremely thoroughly
reviewed reference implementation and test suite would make everybody's lives
easier.

[1] [http://seriot.ch/parsing_json.php](http://seriot.ch/parsing_json.php)

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

~~~
peterbraden
It's an unstructured format, that's the point.

You can't edit a protobufs in an editor.

~~~
yorwba
Maybe not in vanilla text editors, but I don't see a reason you couldn't have
an Emacs mode or special-purpose editor that lets you manipulate protobufs as
text or structured data, respectively.

------
seanwilson
Seeing 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 example, in JavaScript I'll sometimes change code along the lines of

    
    
        a.x = 1;
        a.y = 2;
    

to

    
    
        a = {
            x: 1,
            y: 2
        };"
    

If you eliminate the commas, semicolons and changed the colons/equals to the
same thing, you could copy/paste it with much less hassle.

~~~
coldtea
> _I think Python has things right with the significant whitespace as well as
> it seriously reduces annoying errors caused by misbalanced brackets
> /braces._

You still get errors caused by mis-indented statements which are almost just
as hard to check (if the indent continues for 10-15 lines and is nested etc).

And because of allowing to mix tabs and spaces, you also get other issues.

I think go had the best idea in this with gofmt: all code should be auto-
formatted absolutely the same -- then it becomes trivial to read.

~~~
seanwilson
> You still get errors caused by mis-indented statements which are almost just
> as hard to check (if the indent continues for 10-15 lines and is nested
> etc).

I find wrong indents miles easier to see than unbalanced brackets/braces
though. A single bracket/brace is only one symbol so it's hard to spot but it
completely changes the semantics (see Apple's goto fail error).

> I think go had the best idea in this with gofmt: all code should be auto-
> formatted absolutely the same -- then it becomes trivial to read.

Yes, I like this. There's so many pointless arguments about things to do with
naming conventions and tabs vs spaces...just make it part of the language so
people can argue about more important topics.

~~~
krapp
goto fail was caused by a failure to use braces at all - ironically, it seems,
for the same aesthetic reasons that significant whitespace is used, because it
seems "cleaner."

Had braces been used, the error might have been easier to spot or might not
have happened at all.

~~~
seanwilson
Significant whitespace forces the look of the code and the meaning of the code
together to prevent mistakes like that though. It's really silly that
indenting code within a condition is a universal code formatting convention
but it's not enforced by the compiler. I can't think of any exceptions where
you wouldn't want to indent code like that and it's obvious badly indented
code can be misleading so I don't see why a compiler shouldn't pick that up
for you.

~~~
krapp
The conventions around whitespace and code formatting are not universal, and
the problem is once the compiler has to care about whitespace, it's no longer
whitespace, it's code.

Code has to be correct in ways whitespace doesn't. Some people use tabs, some
people use spaces. Some people even use both. In terms of whitespace, it
doesn't really matter.

But, if your language cares which of the visually indistinguishable but
otherwise incompatible kinds of non-printing characters you're formatting your
code with, then it can still fail while visually communicating the correct
information to the reader.

~~~
seanwilson
> The conventions around whitespace and code formatting are not universal

How is it not though? For every mainstream language it's standard convention
to indent conditions and functions.

> But, if your language cares which of the visually indistinguishable but
> otherwise incompatible kinds of non-printing characters you're formatting
> your code with, then it can still fail while visually communicating the
> correct information to the reader.

This a complete non-issue to me. The pros of significant whitespace vastly
overshadow any possible benefit of letting people choose tabs vs spaces and
the latter issue is easily solved with IDEs anyway. I don't see people having
any issues with this using Python either.

Personally, I think even naming conventions should be enforced by the language
as well so people can stop wasting time debating insignificant details and in
code reviews.

------
aviaviavi
Json5 allows trailing commas. It also allows for comments, so definitely use
json5 where you can

------
setzer22
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, especially in basic data type lists. The only place where I find
commas visually helpful is C-style argument lists (with type and value pairs),
which JSON doesn't even use.

[1] [https://github.com/edn-format/edn](https://github.com/edn-format/edn)

~~~
masklinn
> 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.

------
ape4
Mandatory quotes around the key bugs me.
[https://stackoverflow.com/questions/949449/json-spec-does-
th...](https://stackoverflow.com/questions/949449/json-spec-does-the-key-have-
to-be-surrounded-with-quotes)

Allowing single quotes would be good too. This makes quoting strings that
contain double quotes nicer.

------
fr33k3y
I would love to have trailing commas in JSON but I can see that being JSON
something too widely extended over the internet it's not possible to do it for
real as it will break all around. So, what I do is to have my editor to fix
this issue as I'm completely unable to stop doing it :-)

~~~
StavrosK
Seems like a perfectly backwards-compatible change to me.

------
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/wsl/main.html)

[http://jstimpfle.de/projects/python-
wsl/main.html](http://jstimpfle.de/projects/python-wsl/main.html)

Tell me what you think!

------
pan69
JSON is for serialization, YAML is for configuration.

I agree, trailing comma's and the lack of comments is extremely annoying in
JSON. However, I think the underlying problem is tools using a serialization
format for configuration to be the real problem here.

That AWS CloudFormation has added support for YAML is a great example of this
and it's a great step forward. I think other tools should follow.

------
neomantra
This is one of my most favorite Lua features -- trailing commas are allowed in
table constructors.

When generating code, it is so wonderful to not have to have the logic to
track the first or last object ....

------
demircancelebi
Complainers in this thread might take a look at YAML

~~~
coldtea
People suggesting YAML might want to think long and hard about its horrible
syntax issues, and why it didn't make it as the de facto serialization/config
format as much as JSON did.

------
maelito
Is this only useful for code diffs, or am I missing something ?

Couldn't git take this into account to visually "depollute" diffs ?

------
rini17
Good 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.

------
bostand
I just learned about cbor. Does cbor have this issue too?

------
TomK32
[http://rubyfiddle.com/riddles/2a418](http://rubyfiddle.com/riddles/2a418)

------
stesch
But I want to use eval() in IE8!!

------
ricardobeat
['not', 'my', 'cup', 'of', 'tea',].join(' ')

------
homero
Personal plea is comments

------
keymone
personally i don't like dangling commas.

~~~
ape4
Me neither but it should be tolerated.

~~~
keymone
commas should just be treated as whitespace.

------
skrebbel
And comments!

------
sigi45
NO thats so ugly

------
LoSboccacc
just use yaml for human editable configs

