Hacker News Reader

Comment by beeforpork | Hacker News Reader

In my opinion, a little redundancy is good to avoid rockets falling out of the sky, so I vote for a layout rule plus redundant semicolons. The semicolon is hardwired in many programmers hands anyway. I don't think it should be a design goal to get rid of it. Instead, the compiler's/interpreter's job is to help the programmer to avoid bugs, and with a little syntactic redundancy, the parser can already help out with a few syntax errors. I love gcc's -Werror=misleading-indentation.

View on HN

I unhardwired myself using Swift.

It is painful when I need to use them in another language.

After coding for decades, I’m glad to have one less thing to type.

If we want verifiable code, let’s move up a level of abstraction and build safer languages.

Counterpoint: I find a lack of semicolons entirely natural in ruby and python, and find it equally natural to insist on them in JS.

I have no idea why this is.

Y'know I was just musing over this exact feeling myself. I think some languages are more suited to it than others just by their "look". It's just a matter of trade dress — semicolons just go with curly braces. I find their absence in go jarring too.

What really keeps me up at night is wondering about the semicolon after a class definition:

  class Foo {
    ...
  };

This doesn't get one. It's confusing, but explicit in the ecmascript spec. That form of class definition is called a ClassDeclaration, and they don't take semicolons. I haven't checked, but I think what you've typed here is valid because the parser sees a zero-length expression after the '}'.

The reason it's confusing is because if you modify it very slightly, then the semicolon becomes required:

    let Bar = class Foo {
      ...
    };

In that context, precisely the same sequence of characters as you had before is now called a ClassExpression, and the semicolon isn't attached to the class, but instead to the preceding let.

I do find semicolons useful as an indicator at the end of the class expression that there's a let or a const somewhere above, but it's far simpler to just not do that and pretend that language facility doesn't exist unless you really, really need it.

I suspect it is exactly that simple. It's just what we're used to. However I do have a lot of sympathy with the argument (as here) that one shouldn't use an error recovery mechanism for stylistic effect. Automatic semicolon insertion is for fixing mistakes.

I would even go so far as to say that more characters/typing is objectively better than fewer any time fewer can introduce ambiguity, or confuse downstream (even future self) readers. Longer names are good except where shorter names well known and widely agreed upon idioms (example: I always type `acc` in a `reduce` callback, because that’s the convention; but I always type `index` instead of `i`, because single-letter names are frequently ambiguous). Explicit types at interface/module boundaries are better than implicit/inferred types because they prevent regressions, surprises, breaking changes and sweeping contract changes that wouldn’t otherwise be necessary. Stricter rules are easier to comply with than more flexible rules; typing a semicolon at the end of every statement accepting one is significantly less cognitive load than remembering which ones are special and no more burdensome than correcting surprising mistakes. And those benefits are significantly more valuable than fewer punctuation marks and keystrokes.

Reply on news.ycombinator.com