One would hope that at least over time the bike sheds being argued about would start to at least evolve into arguments about bike garages and eventually bike factories. But I guess the bike shed is forever a bike shed, as long as we're making bikes.
Whatever the next disruption is in software engineering, please dear God let it be immune-by-design to this type of distraction.
Here is what I see:
@fat is not inserting "!" needlessly as a statement separator. The "!" is there for its proper purpose, as a "unary not" operation, which will short circuit the second operand of the "&&" when isActive is false.
Could @fat have written the code differently so that he would have been required to include the ";"? Perhaps -- but I don't see why that counterfactual has any particular bearing here.
The fact is that @fat's code is legal code and JSMin is breaking it.
IMHO, Crockford is ignoring the technical matters at hand. @fat cannot be faulted for writing code that complies with the specification and for having a reasonable expectation that code minimizers will preserve the semantics of his legal code. Crockford (and others) may wish that the language specification did not include automatic semicolon insertion because it does hamper making changes in the language without breaking existing code -- but that does not make this piece of code "insanely stupid".
Yes, forward progress on the language would be better served if automatic semicolon insertion rules weren't in the specification. However, calling one particular piece of code that leverages those rules "insanely stupid" and refusing to acknowledge that JSMin is in fact breaking the semantics of the code is not productive. Refusing to fix this in JSMin does not somehow make the problem with the specification to go away.
Language lawyering is fine and dandy when you know exactly which compiler will be used and you know exactly how it works.
But on the web that isn't the case. You can write code, but you have no control over what browsers, past, present and future, it will get run on. And it is your responsibility to make that work. According to the spec, you may be right. But in practice you're the one who is wrong, because you're the one whose job it is to make your code work across browsers and future versions of the spec.
That said, it's hard to program to a spec that does not (officially) exist yet, and doubly so if there's not clear "opt-in/out" path for future versions. Since, as a developer, I can't control what the committee adds or removes from the spec, or what they might break, I can only do the best I can with the language as it is -- not breaking existing code in future versions of the language is the committee's job.
JSMin is breaking working, spec compliant, cross browser compatible code. How is that not broken?
No one won in this situation, but Crockford should know better by now.
It's one thing to insert semicolons in this case:
<ident> <op> <ident> <op> <ident>
<ident> <op> <ident>
Another distinctive feature of Algol-derived languages is that two adjacent expressions are generally not meaningful; for example, <ident> <ident> is not usually a valid expression sequence in Pascal, C, etc. (and in the presence of typedefs, it is actually a concrete problem when trying to parse C declarations, often requiring communication between lexer and parser to turn typedef identifiers into keywords for the purpose of parsing). This in turn creates freedom for creating new keywords unambiguously, by including whitespace in the "keyword" (actually two words). But JS foregoes some of this, because <ident> \n <ident> will have a semicolon inserted on the line break. It's not too bad though, because new two-word "keywords" are not usually broken over two lines; but long expressions almost always extend over multiple lines at some point.
Do you see what I'm getting at here?
 http://calculist.blogspot.co.uk/2009/02/c-typedef-parsing-pr... has what seems to be a reasonable overview of this problem.
If you don't understand why I take this approach, you will never understand my position.
The infix “!” operator: An eventual analog of “.“, for making eventual requests look more like immediate requests.
I don't think anyone is arguing that x\n!p is a good way to write code. Crockford is pointing out that ASI will not occur when ! is an infix operator.
Your statement thereby makes no sense: this is precisely the kind of argument and conversation--a bug report from a user that itself can be construed as a question about what the purpose of the project is and what parts of the specification it will choose to support--that one would hope the primary maintainer of a project should be "wasting his time" involving himself with.
But any author of a language minification library will have to deal with corner cases. I see no easy way out. Would it be better for Crockford not to have started writing JSMin?
Scrolled through, won't participate. I'd much rather build interesting application.
People tend to have pretty stiff sticks up their arses in such discussions.
Humor, even toilet humor, can remove fear and remind everyone that a debate over a semicolon is not necessarily a life/death situation.
It's like someone yelling and acting up when other people are talking about something important to them, just because that person is bored and doesn't care about the topic.
If you are bored, go somewhere else.
And the net result _every_ single time is that the bug gets locked so no one can post to it. Sometimes they unlock it again after the reddit idiots have left.
I subscribe to quite a few programming related subreddits and while the comments there are more informal (people can make a joke without getting downvoted, for instance) the level of the discussion you're referring to is not very representative of programming subreddits either.
The sad thing is that apparently some programmers take this stuff so seriously that they refuse to learn a language that wont let them use their pet brace style or whatever. I wonder how they collaborate with other programmers or if they would reject a job offer from a company that used the wrong coding style.
This unfortunate behavior is well described by Wadler's Law:
While your sentiment is positive, wouldn't this mean either designing things in a rigid, unambiguous manner (think C's semicolons) or changing human nature? Ambiguous choices plus human nature equals debates. An argument about semicolons does seem silly and your proposed outcome sounds nice, but how could we get there?
Edit: rm js rant
Someone like Crockford with his 'years of experience' opening the debate by saying this kid's code is 'insanely stupid' is the real disappointment for me here.
Not to mention the memes and pictures being posted further down in the thread. I hope it's a matter of time before github comes up with a way to flag these.
"Here is a feature. Don't ever use it. Here is a simple way to do this. This way is dumb, use a 2321 line library instead. There is nothing wrong with X, you just chose one of the 60 wrong ways of using it."
1. I'm going to use three semicolons for every one Fat doesn't use, the arrogant twat! ;-)
2. Bike shed.
3. Some of these arguments actually kind of make sense... I Prefer the semicolonlessness of Python as well. But even though I know the ASI rules, I don't want to spend the mental effort to check every line for unwanted continuation.
4. And then someone linked to http://npmjs.org/doc/coding-style.html#Semicolons which is a style that has marginally more semicolons than Fat would (apparently) use, but I can use this pretty much without thinking.
I might give it a go. See how it feels. It's important to not stick to old conventions just because KIDS THESE DAYS.
If you never hear from me again, it's because I've drowned in an ocean of obscure bugs.
The time is ripe for Dart!
edit: now that I said that, it makes a lot of sense.
The disturbing thing is the idiot arguing about implicit semicolons in a language with not good support for them, in a general use library.