4 ms·
> JSON has its own annoyance that the extra comma on the last field will be a syntax error when other languages let you get away with it. My thoughts exactly.
by btschaegg 9y ago
> JSON has its own annoyance that the extra comma on the last field will be a syntax error when other languages let you get away with it.
My thoughts exactly. I am repeatedly astounded by the fact that McCarthy thought of something abstract as Lisp syntax in the 50s and yet it did take ages for Algol-derived languages to figure out the comma thing.
The case of JSON especially irritates me since its not only supposed to be easy to parse (and - honestly - allowing an additional comma wouldn't be hard anyway), but easy to generate as well...
Also: You know something's wrong when all your SQL templates look like
SELECT
Column1
,Column2
,Column3
,[...]
Just sayin'.
- seanwilson 9y agoYeah, agree with that! Personally, I cannot understand how some people hate significant whitespace in languages. You should be adding whitespace anyway so the braces are redundant and missing out braces is a massive source of super annoying and unhelpful syntax errors where you can be hunting around for ages for the mistake. Incorrect indentation is easy to spot and easy to correct in a few keystrokes in comparison.
- krapp 9y agoPeople hate significant whitespace because whitespace and indentation are meant for human readability. Introducing the potential for bugs into syntax that a compiler or interpreter shouldn't care about seems unnecessary, or at least not superior to the alternative. Incorrect bracing and incorrect indentation are equally easy (or difficult) to spot depending on a programmer's familiarity with the language, the features of the editor being used, and the size of the codebase being analyzed, as significant whitespace is just a more complex and brittle form of brackets that uses multiple, visually indistinguishable but incompatible non-printing characters.
- kazinator 9y agoDropping the silly commas somehow wasn't obvious right away to McCarthy, either! See: https://news.ycombinator.com/item?id=14885779 https://news.ycombinator.com/item?id=14885779 The "Algebraic Manipulation of Symbolic Expressions" was basically predecessor to S-exps, but with commas. The interesting thing is that math notation has some comma-based things (function arguments, sets, sequences) and some that don't use commas (like matrices and vectors).
- btschaegg 9y agoTo clarify: What bugs me about this isn't really that there are commas. If that makes the parsing simpler, I won't mind having to type them, and having them there doesn't make the code less readable. They might not be needed technically, but I can live with that. What annoys me is that you can't end a list in a comma: [ 1, 2 ] is valid, whereas [ 1, 2, ] isn't. This means that if you generate JSON (and if you're using a lower level language you might not want to import a library just for that), you'll have to make a) either the first or the last entry of your sequence a "special case" (omit the comma) or b) backtrack after the string generation and erase the last comma if there are any entries. On top of that, AFAIK Ecmascript allowed trailing commas since its inception (in array literals, that is), while JSON doesn't.
- kbp 9y ago> The "Algebraic Manipulation of Symbolic Expressions" was basically predecessor to S-exps, but with commas. Early Lisp used commas as well. The Lisp I Programmer's Manual from 1960 has a note[0] when moving from a theoretical discussion to discussing the actual Lisp system: "A few discrepancies between the situation as it is and what might be expected from the previous chapter should be noted. 1. The commas in writing S-expressions may be omitted. This is an accident." By 1962, the Lisp 1.5 Programmer's Manual was saying[1]: "Historically, the separator for elements of lists was the comma (,); however, the blank is now generally used. The two are entirely equivalent in LISP." I wonder when we got unquote. 0: page 24, http://bitsavers.trailing-edge.com/pdf/mit/rle_lisp/LISP_I_Programmers_Manual_Mar60.pdf http://bitsavers.trailing-edge.com/pdf/mit/rle_lisp/LISP_I_P... 1: page 4, http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf http://www.softwarepreservation.org/projects/LISP/book/LISP%...
- kazinator 9y ago> I wonder when we got unquote. This subject has some coverage in P. Gabriel's and Guy L. Steele's Evolution of Lisp: https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf Search for "backquote".