[Darmani]

The opinion of an intellectual is indeed stronger Bayesian evidence than that of a layperson. But if they have an opinion, they should provide an argument to back it up, and that argument is far more important.

My first comment hit the advice to always follow Carmack over the random Topcoder user. It's important to understand what makes a best practice a best practice rather than just listening. A Topcoder round and Quake differ greatly enough that the random Topcoder user is sometimes the greater authority.

You seemed to map the call to critically evaluate expert opinion to a call to ignore it, something I'm sure you've seen too much of. But it's important to understand the difference between critical evaluation and anti-intellectualism. Indeed, the former is the higher form of respect.

[freshhawk]

In general I agree completely, standard philosophy of science stuff.

I'm not sure how well it applies to a subject like best practices where it's either subjective or at least fuzzy. The arguments are "in my experience this causes problems when working with other people and is more prone to errors long term". There have been no counter examples or analysis I've seen around this issue, just a "that's just what the traditionalists say" type argument. Something along the lines of your topcoder example that applied to the semicolon argument (god i hate this issue) would be very welcome.

Any critical analysis here is hard to do objectively, and there is a consensus of experts (including Eich) on one side. If i'd seen any actual critical analysis rather than a jump to "don't let the experts tell you what to do! be a rockstar!" then I wouldn't been so fast to use the anti-intellectualism card. But it's so prevalent in the node community (more than Ruby's but less than PHP's) that it's depressing.

[Darmani]

The reason for using semicolons in JS is quite simple: It makes it easy to determine the boundaries between statements, both for humans and machines.

With semicolons, the search for the boundary between statements reduces to the search for that single character -- that means fast code skimming.

The boundary is also robust against changes; as long as that semicolon stays in place, nothing that happens within that statement can cause that boundary to become an interior.

There is an exception: Strings. This is no trouble for machines, as strings are processed by the lexer. Humans can't instantly take a string and process it as a chunk, but a UI innovation does this work for us: syntax highlighting.

As an example, consider the code:

  x = a && b
  foo()

If I try to change the "b", I might accidentally turn the code into

  x=a &&
  foo()

The grammar allows the malformed statement to interact with its neighbor, and thus, instead of getting a parser error, I'll get a program bug.

LR parsers take advantage of this for error recovery, allowing them to find more than one parse error at a time.

A more sophisticated view is to think about syntax abstractions. Given a program like "x=y; return x;" we can create a program written in the abstract syntax "statement; statement". (The dual operation is to concretized that back into the set of all two-statement programs. This kind of relationship is known a Galois connection.) Having semicolons makes the abstract syntax unambiguous, allowing us to efficiently reason at the statement level.

[freshhawk]

We're so off track that it's been lost that all my points are very definitely pro-semicolon?

[Darmani]

You asked for an analysis of why semicolons are good, and you got it.