That doesn't sound right to me. Making s language's syntax more liberal is not a sane way to correct errors. If anything, JavaScript's ASI is an error creation mechanism.
If you try to take your key with you at all times, the super will save your bacon once in a blue moon when you forget your key. On the other hand, if you think of the door as only needing a key when you wish to have it opened on nights and week-ends, you are on your way to trouble.
As usual, analogies do more harm than good, especially when understanding a relatively simple technical issue.
On another topic, this isn’t really a technical issue, it’s a people issue. Everyone understands what the JS interpreter’s behaviour is, what Bootstrap.js does, and why JSMin doesn’t minify it. What is being discussed here is what choices people make to please themselves and others as opposed to the compiler.
If @fat didn’t care about people, he’d use semicolons and JSMin would compile Bootstrap. If Crockford didn’t care about people, JSMin would compile Bootstrap just the way it is. When we’re talking about multiple ways of writing code that does the same thing, it’s almost entirely about people and not technical considerations.
But you don't need analogies to understand why ASI is a bad idea. ASI means that when you leave out a semi-colon you get unexpected behavior instead of a syntax error. Failure is always better than the unknown. At least then there's a chance the bug will be found and fixed.
Proceeds to offer an even worse analogy. Good one :)
ASI is supposed to work in exceptional scenarios where you would have ended up making a mistake but wouldn't want to be reminded of. And that is supposed to be in rare scenarios.
Now if you make exception the norm and expect tools to make up for bad practices then its not going to help.
And this is why I think Python's forced indentation is in some way bad. Because it makes the code from a bad and good programmer both look same. And merely forcing code indentation won't magically transmogrify a bad programmer to a good programmer. There are many things to good programming and indentation is just one of them. Worse it will make both's code look the same.
Forgiving or masking or making bad practices look good doesn't help on the longer run. It only encourages such behavior. I am sure bad programmers can slip in easily into these communities than else where, because they are difficult to flush out and their mistakes are often forgiven or made look good.
<a onClick = "someFunc()" > ...
> Error, missing semicolon after ")" on line 1
That could get pretty annoying pretty fast, and simple little event handlers like these were probably the main use of JavaScript for the first x years. It also matched the existing philosophy of HTML which was to really go out of its way to make sense of whatever was in the file.
Now of course, the constraints are different: people want to use JavaScript for huge codebases and serious projects, so it makes sense that these decisions are no longer appropriate.
Depends whether the semicolon is defined as a terminator or as a separator.
This would be valid code with statement separator semicolons.
"ASI is (formally speaking) a syntactic error correction procedure."
Yet the "expectation of ASI" or (I think more likely) "expectation of newline significance" makes people believe that they'll get a ; inserted by separating two things by one or more newlines.
Most languages do not specify error correction. HTML5 of course does; CSS too; among general programming languages it's much less common. The spec for ASI does not fit in the tried-and-true LR(1) formalism used by ECMA-262. Parsing is not all ad-hoc or equally well-formalized and proven.
In addition to ASI, ECMA-262 has to use lookahead restrictions and a bit of semantic checking to cope with what could be purely syntactic concerns (say, if it could use GLR instead of LR(1)).
The error-correction view seems to want to add a third category, strings that are in some sense "errors", but nonetheless get unambiguously mapped to an AST. Which is strange from a classical formal-languages view, because if a string gets mapped to an AST, it's in the language, and the procedure that mapped it constitutes the parser! That category seems more like "warnings" to me, i.e. you probably shouldn't do this, but it will produce a program if you do.
But that doesn't alter ASI's error-correction nature, which is not an "implementation detail" -- it's in the spec and all too observable.
You're right, it has the character of a warning system, like Dart's unsound "types". But if it had been noisy (consoles in the early days were costly), too many developers would have ignored the warnings, and users would have paid for the overhead.
Your concluding sentence is spot on, I agree people should use semicolons in JS. Relying on a Ruby-like coding style in the large is way too risky.