Hacker News Reader

Comment by seanwilson | Hacker News Reader

I love that the syntax doesn't require commas at the end of field assignments to be honest. Anything that lets you copy/cut and paste lines around without having to jump the cursor somewhere after to add things like commas or braces to avoid annoying syntax errors is great. I like significant whitespace languages like Python for the same reason and syntax like OCaml's where you omit brackets for function calls.

View on HN

I dislike the way it looks like JSON but isn't.

My opinion is that QML not going to supersede web tech any time soon. As broken as CSS is, it is here to stay for the a while yet. The tooling for QML isn't great. You're heavily relying on QT Creator etc and the licensing around all that stuff. The exact opposite of FOSS that the web embraces.

Also FWIW, I know it's a holy issue but when you copy lines round in python etc you ARE having to add and remove those extra bits of syntax except they're invisible, they're spaces/tabs (don't even). Any sane person would have to have white space visibility turned on in their editor so would just be looking at cruft anyways.

> I dislike the way it looks like JSON but isn't.

Sticking on the topic of syntax, 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. A field that goes over two lines is the exception so there should be a more verbose syntax for that rather than for single line fields in my opinion.

> As broken as CSS is, it is here to stay for the a while yet.

I prefer SASS with significant whitespace, no semicolons and no braces. :P

> Also FWIW, I know it's a holy issue but when you copy lines round in python etc you ARE having to add and remove those extra bits of syntax except they're invisible, they're spaces/tabs (don't even). Any sane person would have to have white space visibility turned on in their editor so would just be looking at cruft anyways.

Hmm, so in pretty much all IDEs, I can paste Python code then do TAB or shift+TAB to fix the indentation level as what you pasted is still selected. Having to add e.g. curly braces/bracket to fix nesting is miles more cumbersome and error-prone when there's a syntax error. It's super irritating trying to work out where the missing brace/bracket is.

I'm less concerned how it looks and more concerned how easy it is to move lines of code around plus find syntax errors. I'm still amazed how bad syntax error messages are at helping you work out what's wrong.

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

Yeah, 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.

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

Dropping the silly commas somehow wasn't obvious right away to McCarthy, either!

See: 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).

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

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

1: page 4, http://www.softwarepreservation.org/projects/LISP/book/LISP%...

> 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

Search for "backquote".

> You're heavily relying on QT Creator etc and the licensing around all that stuff. The exact opposite of FOSS that the web embraces.

I don't understand what you're getting at. Qt Creator is FOSS. https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/

Reply on news.ycombinator.com