There's something horribly wrong with everything about this. Why is such a smart person as Crockford wasting his time arguing about semicolons in 2012? Why is this at the top of the most popular hacker website? Why are people writing detailed opinions about semicolons in this thread (with surely more to come?)
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.
Jacob ("fat") comes off looking far worse than Crockford, to my eyes (and that Kit character seems to be 7 years old). It's the arrogance and stupidity of youth facing the crotchety crankiness of experience. Crockford has earned the right to have a strong opinion here IMO.
But it's not just bike-shedding. It's more pernicious than that. It's actually something that looks like bike-shedding to uninformed observers, but something that strongly affects cross-version compatibility. Javascript does automatic semicolon insertion by taking advantage of potentially ambiguous constructs that happen to be resolved in one way right now. But they may be actually ambiguous in the future - in the case where a unary prefix operator becomes a binary operator. Language extension usually works this way: a previously unambiguously wrong statement is made valid; but JS semicolon insertion often turns "wrong" statements into "correct" statements, so it leaves less "entropy" to be taken advantage of when increasing the power of the syntax. I think there's a strong case for JS to not insert semicolons here, and I agree with Crockford's position on not handling it in JSMin. It's the right thing to do.
I have never written a line of JS in my life, which hopefully qualifies me as an unbiased outsider, but I don't agree that that Crockford's position here on JSMin is the right thing to do.
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.
Given that, @fat has left out a semicolon in a way that is perfectly legitimate based on this language specification, at least as described in the 5.1 version linked from here: http://inimino.org/~inimino/blog/javascript_semicolons).
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.
Crockford's own page on JSMin <http://www.crockford.com/javascript/jsmin.html>; claims: "JSMin is a filter that omits or modifies some characters. This does not change the behavior of the program that it is minifying."
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.
Crockford is releasing a tool which is compatible with his opinions, not with JavaScript. All browsers execute that code fine, present and past, and at least for the next decade or so.
Crockford can be an arrogant ass about this stuff, that's why jshint exists, because not agreeing with Crockford does not mean bad JavaScript, no matter what he would have you believe
In this case, it's not language lawyering. All JavaScript environments "do the right thing" with regards to ASI -- it works in all target environments as of the present day. JSMin is not a target environment, it is a minifier that happens to express some strongly-held opinions of its author.
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.
No one ever earns the right to be a jerk. Crockford can have a strong opinion all he wants, but if he wants people to continue looking up to him, he will explain and conduct himself in a civil and professional manner.
No one won in this situation, but Crockford should know better by now.
I'm uninterested in any specifics, actually; I'm more interested in how much of the syntax landscape is cut off for future extension, particularly at the expression level.
It's one thing to insert semicolons in this case:
<ident> <op> <ident> <op> <ident>
<keyword>
and another to do so in this kind of case:
<ident> <op> <ident>
<op> <ident>
The former is unlikely to be problematic for future extension, but the latter more so. The general pattern in Algol-derived languages is for all statements (except for expressions, including assignments and procedure calls) to begin with a keyword. This substantially reduces ambiguity - semicolons are mostly redundant in this situation - and it seems to me to be a fine place in JS to automatically insert them.
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[1]). 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.
The 'latest revision of the future specification' you link to is, I think, the set of things the TC39 group has considered and agreed on. The list of things they are currently considering is in the strawman namespace[1] on that wiki. In particular, the "strawman:concurrency" page[2] currently says:
The infix “!” operator: An eventual analog of “.“, for making eventual requests look more like immediate requests.
... Crockford is the developer of JSMin, and was explicitly dragged into the conversation because people claim (possibly correctly) that it is a bug in JSMin than when it is given code with semi-colons that are missing in places that the JavaScript specification claims are optional (possibly also stupidly), it generates output that is not semantically equivalent to the original code.
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.
I wasn't literally asking why is this happening. I was pointing out that it's sad that we live in a world where someone like Crockford is spending brain cycles talking about semicolons, regardless of the reason.
In the big picture, I agree that everything about the GitHub thread, meta or not, is terrible.
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?
I would hardly call this an "argument" from Crockford. There is absolutely no back-and-forth. Crockford is told there is a bug (or perhaps, a missing feature) in his software. Crockford responds that he will not change his code, and that the first guy's code is bad. Other commenters then begin arguing, but Crockford does not.
I found the whole discussion quite sad, the stupid animated GIFs in particular. I became even more sad when I noticed the discussion is being held on GitHub, not Reddit or 4chan.
Scrolled through, won't participate. I'd much rather build interesting application.
I wonder when bug tracking sites are going to block reddit referrers (or just prevent them from posting). I've seen this before in comments to PHP bugs and bugzilla bugs.
I disagree. Imho a little infantile humor in places where it "doesn't belong" can be quite refreshing - as long as it remains the exception rather than the rule.
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 said something same-ish, but it seems HN is full of true professionals, with no place for humor in their work --or internet procrastination time--, that never read MAD magazine as kids...
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.
I felt the same way. Once I got to @pyalot actually belittling @shawnpresser's JSMin fix, I realized just how religious and immature this debate had become.
This is one of the many reasons why I love Go's pragmatism. gofmt is the end of all this kind of silly unproductive arguments.
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.
P.S.: Also Go's syntax manages to keep code semicolon-free while avoiding the pitfalls of JavaScript.
This is great, thanks. The only logical conclusion is that engineers should be choosing tools that have the least syntactical surface area to argue over. :)
jep, see Eiffel. Convention is indexing from 1. (but it allows you to do it in whatever way you want, start from 3 if you want, because hey why not -.-)
What's wrong with it? It's like arguing about grammar. We've been going back and forth on the Oxford Comma for at least 300 years now, with no end in sight.
Whatever the next disruption is in software engineering, please dear God let it be immune-by-design to this type of distraction.
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?
You say "rigid, unambiguous manner" as if it was something bad, not agile, boring or uncool. I disagree with this way to present things. A good computer language should have a solid unambiguous syntax (think lisp), upon which we can build agile tools and avoid the daily useless messes we get from JavaScript.
My point wasn't that arguments are avoidable altogether. It was simply that one would hope the arguments would evolve in complexity or at the very least change in specifics. Since that doesn't seem to be happening, and the same old tired topics keep coming up, I think it's important that designers of future software engineering tools consider how immune their systems are to the grab bag of arguments we've been hearing since the 1970s about syntax and semantics.
We already have something akin to that - Python (PEP 8 specifically). People still find things to argue about though, presumably because they enjoy it. On the upside, it happens less often!
Whilst fat doesn't come off great he has youth and inexperience on his side.
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.
Well, yeah. That's a large part of the reason I don't like the hype around JavaScript.
"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."
I don't want to think about this kind of stuff, I have enough to worry about as it is. JavaScript is all right as a language of the present, but I really don't want it to be "the future", like many people paint it to be.
While whether or not to use them when designing a language is bikeshedding, JavaScript already has so pitfalls caused by semicolon insertion, their use is a must.
Yes/no/sort of, I actually found this an quite enlightening discussion. My opinion went from:
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.
>There's something horribly wrong with everything about this. Why is such a smart person as Crockford wasting his time arguing about semicolons in 2012?
The disturbing thing is the idiot arguing about implicit semicolons in a language with not good support for them, in a general use library.
Jacob is an idiot for writing code with a ridiculous fragile syntax that takes more effort to write in a vain effort to obtain "coolness" via winning a pointless language war that nobody on earth cares about.
Crockford is an idiot for writing an JS minifier which explicitly promises to not break legal code but actually does, and then refusing to fix it because he's proud of his reputation for being an asshole.
And everyone commenting on this post is an idiot for thinking that any of this is worth the pixels it takes to argue about it. And yes, that includes me.
I'm new to JavaScript, but from what I can tell, the no-semicolons style
- is incompatible with existing tools
- is incompatible in places with upcoming versions of JavaScript
- is harder to refactor, since you might need to add additional tokens to the beginning of lines depending on the previous lines
- is confusing to new JavaScript programmers, since
+ it goes against the recommendations of many of the most popular books
+ it requires adding tokens to the _beginning_ of lines in places, making the entire enterprise more challenging to learn and of dubious utility
+ it discards one of the attractive qualities of JavaScript for programmers of other languages: familiar syntax
And further, the use of constructs like
!somethingHappened && otherwiseDo(x)
instead of
if (!somethingHappened) {
otherwiseDo(x)
}
is bad practice in any language.
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
- Brian Kernighan, "The Elements of Programming Style"
Although everyone has the right to maintain their projects with whichever style they prefer, given the above, I wonder why the chosen style was chosen.
The semicolon wars frustrate me. We have an arbiter of what's correct/valid syntax and what isn't. It's the freaking lexer, heaping additional prescriptivism on top for something as trivial as semicolons is irritating. If your code has ambiguity problems, fix it by writing unambiguous code. Semicolons are not the only way.
This boggles my mind. Why would someone use a convention that brings in ambiguity, when they could just type a semicolon and avoid all the problems of ambiguity in language parsing?
Frankly this is less about semicolons and more about two people who both have strong opinions and feel that they need to act in a certain way.
It doesn't take a lot more effort to rephrase fat's response to be more cordial.
"Hi @englishextra, those two lines are valid JavaScript. We try not to use semicolons whey they aren't necessary. See (insert link to the wiki).
"JSMin doesn't perform well on bits of JS like this. Maybe you can discuss it with @douglascrockford ?"
Flamewar avoided (probably) and more stuff getting done.
I agree. The real problem here is the complete lack of courtesy from either party. Software developers seem to have problems with this, maybe because we spend so much time commanding machines to do things with brief statements without the even the least bit of a please or thank you.
Learning the minutiae of a language is important, sure, but I can't fathom why you'd willingly introduce unnecessary fragility or overthink into your codebase.
Ideally, your goal as a hacker is to make cool shit. Your goal is not syntax.
This is precisely correct. "Don't do x, except in one or two cases where you have to, and then you can hack around it using y instead of x" - rather than "use x by default."
Simplicity should win; but alas, being one of the cool kids is more important.
I think older programmers will side with Crockford and for good reason.
The bootstrap code makes assumptions about the future of the js spec and browser implementations that aren't safe. Young people don't remember the dark days of people writing js to leverage IE/Netscape specific bugs which then had to be turned into features because so much code existed in the wild that could be broken.
Crockford is a scarred veteran of the spec wars. I'm sure that when he sees young people trying to game spec/implementation ambiguities, he thinks, "Never again! Not on my watch!"
I think best practice is explicit, future-proofed code that doesn't tie the hands of spec authors or browser vendors. I know that Crockford's tool doesn't accept the current spec or browser behaviour, but his choice is informed by past experience and concern for the future. It's not just some random bug that he's too stupid or stubborn to fix.
I am not experienced with javascript, so I don't understand this argument. Can someone please confirm the following, or explain what's going on?
Here is what I understand:
1. Javascript will add a phantom semicolon at the end of each line if it seems like you need it, for some definition of seems like. To me, it sounds like this is so that new HTML writers in '98 wouldn't see their pages blow up when they forgot a semicolon at the end of a script. It doesn't sound like professional programmers are expected to leave semicolons out on purpose (this is the opposite from python). The bootstrap authors took advantage of this because somehow screwing with the compiler is in vogue.
2. Crockford's tool broke when a semicolon was left out somewhere. I guess he didn't implement a proper js compiler that covers the entire language spec.
3. There's some business about unary and binary ! operators? Something about sticking a ! in front of your line lets you leave the semicolon off the end? This sounds utterly braindead to me. It's no fewer characters, and the thing you're typing is going really far away (at the beginning of a big block of code) from where it's actually meaningful to you (at the end). Also, it looks like it relies on some fairly convoluted unintended consequences of the spec, that may not be future-proof.
Here is my analysis, if the above understanding is true:
1. Bootstrap needs to fix their code. This business of the compiler sticking in semicolons where it thought you meant them is a crutch to prevent stupid errors from being fatal errors in the average case, but that doesn't mean they aren't errors. Be explicit.
2. Crockford should fix his tool soon, not complain about other people's code, and say "I'll fix it soon, but for now, here's a workaround: just put a semicolon in your code".
3. What the hell. Are people really doing this? Is the web one big obfuscated javascript competition? What happened to writing simple, explicit, readable, maintainable code? Are we really bickering over single characters and trying to play subtle tricks with language esoterica to save them like a bunch of 14-year old perl newbies? Man, I hope these morons aren't in charge of my bank account.
Overall, I'm with Crockford, but he doesn't need to be this much of a jerk about it.
Further analysis, now that I've read it with a decent (non-cell) data connection: allowing gifs in a public issue tracker is a terrible decision.
That is a pretty good rundown of the rules. The only problem with not having semicolons is cases like this, where someone is using a bad tool to minify your code. None of the tools that currently do the best job will break on that code.
Yes, tool writers need to understand this behavior and handle it.
But I still don't understand why the hell you would want to do this. These are a lot of rules to remember, and I don't think it makes sense to think about them for each statement I write. Nothing here says "here is what you gain with this technique", all I see is "it's perfectly valid so quit whining". This doesn't satisfy my curiosity.
Then we have this:
For example, instead of this:
foo();
[1,2,3].forEach(bar);
you could do this:
foo()
;[1,2,3].forEach(bar)
The advantage is that the prefixes are easier to notice, once you are accustomed to never seeing lines starting with ( or [ without semis.
So now the argument is "don't worry, you get used to writing stupid looking code"? This is getting depressing.
starting a line with a semicolon means "start a new expression", if it is done where it is meaningful. By putting it at the start of the line, it is easier to associate it with the statement that makes the character important, and calls out that you are paying attention to one of the biggest gotchas in the language
putting a semicolon at the end of every line is basically just noise. You get used to it, and I find semi-colon bugs end up happening much more frequently. More then that, you are essentially just typing an arbitrary character 99.99999% of the time. When you need a semi colon is essentially a corner case, so the vast majority of code is just getting appended with a character which has no meaning.
Its like the javascript community decided to surround all expressions with parens, since it makes things more explicit, and there are a few cases (much more common then semi colons) where you need it in the language. Or if they decided to end all lines with //, just in case someone wanted to follow it with a comment. Those two examples make as much sense as advocating semicolons at the end of each line.
No. Semicolons are statement separators. Every other language that uses them as such puts them at the end of every expression, but it's fine if you want to put a semicolon at the beginning of every expression instead, except that that will confuse people coming from other languages.
What's not fine is pretending like javascript has significant whitespace and then...oops! it doesn't work here so we need to add something in this one special case. That is guaranteed confusion. If your only argument is that most of the time it's unnecessary, all you're really trying to accomplish is compression (guess what, JSMin does that!) and you may as well write APL. "You get used to it" is meaningless. You get used to banging your head against a wall too, if you do it long enough. Doesn't mean it's a good idea. It's actually worse than that though, because other people need to get used to it too, so you're wasting their time as well.
Surrounding all expressions (not statements) with parens does make sense, in many languages (because there are cases where you need them, and it pays to be explicit up front). That is something good style guides often dictate (like surrounding all if/else blocks with braces, even if they're only one line). Starting a comment after every line doesn't seem like a good analogy, I have no idea where you're going with that.
Let me be clear, and I've now wasted a bunch of time reading up on this so it's not just opinion: ASI is a crutch added to the language in order to minimize the effect of silly errors. It is not a language feature. Python was designed to have significant newlines, and they resolved the ambiguous cases. Javascript was designed to have semicolons between statements when written correctly. Abusing ASI is error-prone and not future-proof (against programmers, apparently language spec changes are going to maintain current behavior). If you think its abuse is a good idea, you should be quarantined from the rest of the programming community. Or write your own language and design it around this.
My argument is that ending every line with // is just noise, () is just noise, and ; is just noise, except for the one in 1000loc time that it isn't. And filling your code with noise not only makes your code harder to read and longer to type (if even by a little bit), but it trains you to ignore semi-colons, especially since you do not have a compiler complaining when you miss them. And when semi-colons fade into the background, it is MUCH harder to catch the one case where they are important.
If you were to write ruby, smalltalk, perl, google go, python, coffeescript or any of the other languages with asi, you find that people omit the semicolons in every situation unless for the few they need them, and never run into a problem. For some reason, that is not the case with js. Do all of those other languages "abuse" ASI? I work on a 500k loc ruby app, and I feel very confident in saying there has never been a single case of a bug from an ambiguous statement from asi (although there have been from the difference of && and 'and'), and there is only about 5 semi colons in the whole code base.
Now, js is different then those other languages in that it has a quirk where it treats whitespace and newlines the same for all types of brackets. Realistically (if you are writing for the browser), this only comes up in lines starting with an open parenthesis, since that is the one case where starting a new statement on a line with any kind of bracket makes sense. And even then, the one time you are likely to be doing that is for an immediately invoking function (function(){}()), which isn't exactly you do every few lines of code. So you have a choice on how to deal with this one, fairly uncommon case; either handle it in a special fashion when it occurs, or put a semi colon on every other line. I don't care which one you choose, all I ask is you afford me the same respect :)
My intent isn't to get into a silly language argument over this, but it seemed like you genuinely missed what I was trying to say. If you feel it would personally help you write better code, then more power to you. But I write a lot of semi-colonless code in various languages, and it has literally never caused a problem for me.
Ending every line with // is noise because it means nothing to the compiler or to the human. If I could write comments without prefixing them with //, I would (but the compiler won't let me). () and ; are not noise because they simplify the rules of the language. They make it so someone reading your code needs to remember fewer esoteric rules to understand it. That is a big win. Saving a single character of typing per line, for your fingers and your disk, is a miniscule win. I hope you're writing code that's more interesting than a typing contest (but if you aren't, maybe you care about the semicolons). The disk and the network don't care about one more semicolon per expression. They know about compression, they will deal with it. If your compiler doesn't complain when you miss them, you need a better compiler. Maybe a linter, or google's closure. Or maybe there's a market for a decent javascript compiler. I don't understand what you mean by "when semi-colons fade into the background, it is MUCH harder to catch the one case where they are important". If you use them everywhere and you miss one, it's easy to spot. If you have to examine each line with a set of rules in order to figure out if you actually needed one there, that's a more expensive task.
Ruby, python, and coffeescript were designed with significant newlines, and therefore designed around the corner cases. The only reason you'll need semicolons in those languages is to have two statements on the same line (coffeescript excepted, I'm not sure about it but my guess is that they did it right). These languages went to great lengths to reduce the cases where you need statement separators, and document this behavior widely and clearly. Perl requires semicolons, dunno where you got the idea it didn't. I don't know about smalltalk and go, I don't use them.
I probably did miss what you were trying to say.
In languages that weren't designed with significant newlines, everybody uses the statement separator at the end of a line, so it seems to me that moving them to the beginning of lines is just confusing. In any case, ASI is not significant newlines, it's a hack. I don't know what more to do than to just beat it into your head. It is not a feature you should rely on.
The important part of what I'm trying to express is that, in any language, the most important thing you need to do is to write explicit code. This means typing all the characters so that not only does the compiler (and tools) not get confused, but future human readers don't get confused either. Javascript intends for you to separate your statements with semicolons. If you start playing tricks with them, you are going to confuse people that try to understand (or, heavens, learn from) your code. You will get burned.
Consider this example (I'm a C guy):
if (a && b || c && d | e || f && g)
How does this resolve? Does it help you if I write this?
if ((a && b) || (c && (d | e)) || (f && g))
It sure as hell does. Now, these are semantically identical. But when you read the second one, you don't need to know that bitwise OR binds tighter than logical AND, and logical AND binds tighter than logical OR. These are details you should not need to remember when you read my code. Are parentheses just line noise here? I think not. I think they are quite meaningful. Not to the compiler, but to the human consumers of my code. It's costs the reader a lot more to read the first one than the second. The first one is mentally expensive. (In fact, modern C compilers will warn you about not having these parens here because they know that adding them is a good idea. If you turn on warnings.)
The same applies for ASI. If you rely on extra compiler tricks a human needs to remember, that's expensive. It is a lot better to have a simpler rule: just put a semicolon after every statement, and don't make anyone think about it again. Or put one before, I don't really care. Just do something consistent. Try to code to a simpler subset of the language, to make other programmers' lives easier.
I really don't mean this to be an attack against you or the javascript community. Well, I sort of do, because abusing ASI is stupid, but I actually mean this to be an educational experience. Let me help you mature as a programmer.
I wonder if the "insanely stupid" comment isn't about the omission of the semicolon but about the omission of "if". Since when is a good old-fashioned if-statement out of style?
The minification isn't breaking the code. The authors had an incorrect expectation of how JSMin would minify the code. By the very act of minifying code where new lines matter your are always potentially changing the behavior.
The minification is breaking the code. If a minifier takes valid JS in and produces JS that behaves differently from the input, then that minifier is broken, full stop. It doesn't matter how anyone personally feels about ASI; what matters is that ASI is a part of JS, so if you're making a tool that processes JS, you need to respect its rules.
Read the bit about TC39. "This code will break in the future." There's no point in patching the minifier to support this when the patch will have to be reverted pretty soon anyway.
I still maintain this is a bug in jsmin, but as others have pointed out - mark and I do our best to make bootstrap flexible with other great tools out there (like jsmin). This includes adding semicolons where necessary or changing minor stylistic things.
I happen to agree with Crockford on the omission of semicolons. I also have a strong opinion on clever code: you should always optimize for readability over aesthetics.
But... Crockford could have said it in a much more tactful way that could elicit a more positive response, spare the world from this sad discussion, as well as channel the man-hours dedicated to this into more useful endeavors.
Future versions of JavaScript might also replace the 'function' keyword with a picture of a chicken, but I'm still going to keep typing the word 'function' for now.
“…Explicit is better than implicit…
Readability counts…
In the face of ambiguity, refuse the temptation to guess.
There should be one—and preferably only one—obvious way to do it…”
— The Zen of Python
Ironically, the Zen of Python supports using semicolons in JavaScript. Also, both sides come off like children, but at least Crockford's opinion seems a little less selfish. It's like politics, with the difference being in their premises so they'll never agree.
Also, why can't I (or anyone else) resist commenting on this rather pointless debate? I am disappointed in my weakness.
It is hard for me to understand how one could make so many things in a programming language completely arbitrary - I mean it is natural for a language designer to have some vision of how the language will be used by other people, how will the common structure of the programs look like, but JavaScript looks like such a vision never existed, there are often several ways of doing the most basic things (writing vs. omitting semicolons mentioned here, writing vs. omitting "var", but above all else 1000 of ways of doing OO, all with it's own problems) and no easy ways at all of doing other very basic things (modules/namespacing). As a result you can find 10 or 20 programs written in JavaScript where each looks like it was written in a quite different language. Maybe it was an attempt to make an "easy" language for non-programmers (I doubt even this goal was in the end achieved), but as a primary language for programming client-side applications it is a utter disappointment. Not that I necessarily blame the JavaScript creator, I am sure there were plenty of corporate pressures involved and other factors of corporate/economic nature.
I wish we could get some other programming language implemented in all the major browsers, then at least in the perspective of the next 10 years we could completely get rid of JavaScript, I am not sure if it possible to really improve the situation in a radical way just via incremental changes to the existing design.
Excellent - another internet cock-fight, with both sides managing to act like total cocks..
What would be better is for both sides to fix their code:
Crockford to fix minify for the edge cases like this (result: better, more robust code equals a win), and the twitter boys to add a semicolon for these edge cases (result: better, more robust code equals a win).
But instead, as usual on the internet, it's just devolving into lots of "waah waah waah".
What is insanely stupid is abusing the logical bitwise && operator rather than signifying their intent using a plain old if statement like the language intended.
For those that agree with leaving semi-colons out of JavaScript that they write for projects, can you explain what the benefit of doing so actually is?
Seems like people are valuing aesthetics over producing code that works for 100% of the users/situations.
Why is this discussion about semi-colon insertion and not about the use of short-circuiting as a replacement for specific 'if' statements and general inconsistency in the project?
(Incidentally, would lines 54/56 of bootstrap-modal suffer from the same problem? Or does the fact that the last function call on line 54 is already in an && expression change things)
The use of semicolon as best practice was sorted out years ago in the js community. Crockford has all his rights to tell these guys to sharpen up because that "fat" character is obviously a python smuch with no knowledge of JS history or respect for elders.
I've seen a few reasons. The main ones I encounter are: raising the skill requirement to contribute (you have to know JS better than average to never use a semicolon, and do so correctly), aesthetic (fewer characters looks better), and minimalism (don't use what you don't need).
That's insane. Good programmers need not know stupid tiny nits about Javascript (heck, I've worked on a Javascript JIT and I don't really know Javascript). That does not mean that they are not skilled.
> aesthetic
I don't understand how "you must carefully understand how the language parses to understand this line of code" is aesthetically pleasing when compared to unambiguity.
> minimalism
Here, it is needed, at least arguably (by douglascrawford). You could argue that the "optional semicolons" rule is ugly and not minimalistic, and thus the minimalistic approach would be to not use that rule.
Sure the "raising the skill level" bit is just trolling. Omitting semi-colons is about removing ambiguity, and making it easier to spot inconsistencies. As a bonus, code looks cleaner.
In this case, the minifier is breaking the code, regardless.
Can you parse this expression without parentheses?
a && b && c || d || e + f > g && h
The parser sure can. Do you have all the operator precedences memorized, or do you use superfluous parentheses because you're not always sure?
It's true that the semicolon is not needed, and it's true that the minifier is breaking code. It may even be true that Crockford should fix it. But that doesn't change the fact that the omit-the-semicolons position is absurdly immature hipster posturing that serves no engineering purpose.
Do you use parenthesis to denote order of operations in all cases, even when extremely obvious? If not, should we assume your position is absurdly immature hipster posturing that serves no engineering purpose?
I'm sure there is a whole huge debate here that I'm unaware of, but it seems like a largely aesthetic choice to me, and on that basis, I find it really jarring as someone who is not an everyday JS author.
Same reason people don't use semi-colons in Python, I imagine.
Besides, I'm not willing to acknowledge any reasons for using semi-colons as significant. And without any significant reasons for it, I may as well not use them. Besides, it makes the code prettier :).
I always think of using semicolons like using parentheses when doing math in code. It makes the order of operations explicit rather than implied. For example,
1 + 2 * 3
Solves to 7, obviously. But I'll write it in code like this:
1 + (2 * 3)
Just to make it clear that I know what I mean, and I mean do the operations in _this_ order.
Similarly, using semicolons to end lines means I am saying loud and clear... this line of code ends HERE.
Amusingly, I agree with your premise but not really your conclusion. Adding a semi-colon is like adding parentheses. But I think redundant parentheses add visual clutter--unless I have a very complicated expression, I leave them off. (Maybe it's the Haskell code style rubbing off on me...)
So I actually think that 1 + 2 * 3 is better than 1 + (2 * 3). I usually find reading a line with less stuff easier, so I prefer the shorter between two equivalent expression.
Besides, adding a semi-colon is more like surrounding the whole expression with parentheses rather than just grouping. And you would never write (1 + (2 * 3)). And yet that also says, loud and clear, the same thing!
I've used some languages with optional semi-colons--Python and Haskell, for example. I've never thought that missing them made the code less readable--it's always been the opposite. Going back to Java and having to use semi-colons everywhere becomes increasing annoying as I grow more acclimated to languages without.
In short, I see where you're coming from but don't really agree.
Is it obvious that there is a missing semi-colon at the end of line 1? The code is technically correct without it (not that I approve of it). You can assume it's wrong, but it's just a guess.
If your code is in no-semi-colon style, there is no ambiguity, you can be 100% sure that this is a mistake: there always should be a semi-colon guarding that parenthesis, regardless of intent:
var value = x + fn
;(y).burp()
It's about removing ambiguity and visual clutter with a simple set of rules.
How many JS programmers know the difference between a function expression or declaration, and the semi-colon that should follow or not? You're dependent on a linter. Following the no-semi-colon rules makes your intentions clear in every case, without machine validation.
I don't follow this argument. Putting a semicolon at the end of every statement, regardless of what follows, seems to be an even easier way to avoid making this bug.
I think the usual semi-colon-less style is to put a semi-colon in front of lines beginning with parentheses (and only those lines). This is the one potential problem area if you don't have semi-colons everywhere, so you can avoid almost all (or maybe actually all) problems just by prepending a semi-colon to those lines.
I think Ricardo's point is that this style (having a semi-colon only before parentheses at the beginning of the line) makes your intentions more explicit.
> Putting a semicolon at the end of every statement
Sounds like a viable strategy - but you have to parse where every statement ends in your head. The situations where you don't end a line with a semi-colon are more numerous than the rules you need to write semi-colon-free code. Besides, if it's so simple, why not leave it to the interpreter?
It's trivial to parse when statements end in my head, because I write code in a structure that makes it unbelievably clear where statements begin and end (with or without semicolons.) Knowing that is of prime importance to human readability, so it has to be dead obvious or the code sucks.
I'd love to leave it to the interpreter, but the interpreter doesn't put a semicolon at the end of every statement for me, as I write them naturally. It puts a semicolon at the end of... most statements.
This is a silly example because it's so simple. E.g. You can just write 2*3+1, which is easier to read. Regardless, I'd wonder why you put the parenthesis there, as if it were some odd hack or workaround for some obscure bug.
My comment from the thread, buried under many pages of meme gifs:
>>>
@douglascrockford If TC-39 makes ! an infix operator, which causes \n to not terminate the statement, then that will be a syntax change that is incompatible with current code in the wild, which would be an insanely stupid move on their part.
The fact of the matter is that JSMin isn't parsing JavaScript correctly. I thought the separation of concerns was that JSLint tells you about stupid code, and JSMin correctly parses JavaScript according to the ES standard and minifies it safely.
Am I missing something? Aren't Bootstrap and JSMin open source? Instead of focusing on coding philosophies, someone can simply fork JSMin's source and make the appropriate patch, or make a fork of Bootstrap that has JSMin friendly code.
Regardless of our many diverse opinions, Crockford and Fat are entitled to maintain their own libraries in whatever fashion they desire. The fact that they made the libraries open source means "if you don't like my code or the way it works, here's my code, customize it and leave me alone".
Allow me to explain further, as I've been down-voted a few times.
My point is that its stupid to use a tool on code it was not written to support. If you want minification with valid JavaScript, use something like Uglify-js.
If you write code, however, that works with JSMin, then use that tool. Douglass Crockford can write his software to work any way he likes and support any code he likes. Don't like it? Use something else, and don't be stupid.
No, it just makes things worse. If people are going to follow the spec, they should follow it and reject bad input. Otherwise, you get a mess of code that tries to guess at what to do. This leads to inconsistencies, possibly security bugs.
Imagine if invalid HTML had been flat-out rejected by browsers since the beginning. Cross-browser compat would be, at least, somewhat easier due to less bad HTML surviving in the wild, since it simply would not have worked. In XML, for instance, I've never heard of the need to deal with invalidly formatted messages.
There's enough problems interpreting semantics, why do folks want to add syntax to the problem, too?
Real question is... why not just use UglifyJS or any one of the other js minifiers? So what Crockford is opinionated about JS, we all know this. Don't use his products if you don't like his opinions.
The problem from my reading of it is that "all the right places" changes meaning depending on which specification of JS you're talking about. But yes it would work if you run into the problem and the semicolon-inserter targets the right spec.
you don't have to use linebreaks either but people use it. There are lots of good practices making code easy to use, read and maintain. So just put f.. semicolon.
That's really stupid. There's no plausible reason that the end of that method shouldn't have a semi-colon. I honestly wouldn't advise anyone use Twitter Bootstrap. You should always use semicolons in Javascript even if you're hippie. Hippies use coffeescript.
And I think Google's style guide[1] is prevail over Github's style guide[2].
Crockford's stance is annoying purely because it's pedantic and because there are many libraries that embrace this style. We use django_compressor and found bugs from the compressor that uses Jsmin. So I have to use something else to compress them before hand.
Are there compressors that use the syntax tree rather than transforming the source?
There's a whole hipster movement going on right now around the idea of omitting semicolons from JavaScript code. I believe CoffeeScript is the culprit.
Kind of funny that you say this, since CoffeeScript inserts semicolons.
The lack of semicolons is the one major thing in the Github style guide that I think is stupid. It seems silly to avoid using semicolons in Javascript because it actually takes a little bit more effort than just using them.
On my team we've decided to use semi-colons in JavaScript for this exact reason: It would actually take more effort to stop using them as our other major language is PHP. More effort for no benefit is pointless.
Driving without a seatbelt would be perfectly reasonable if I had a written list of all possible accidents to drive around. The twist here is that the one and only grammar change that could break this code may actually happen soon. Until then, though, the code is valid and Crockford is intentionally leaving a bug in jsmin.
Because standard-compliant JavaScript implementations don't require them (ECMAScript describes a model of "semicolon insertion" that implementors are supposed to follow).
Not required doesn't necessarily mean it's a good idea.
If they were never needed I'd understand, but sometimes they are. I don't see the point in forcing the developer to make a conscious decision on whether to include a semicolon.
Omitting semicolons also means that the correctness of a line of code is determined by the unrelated lines that follow.
While the virtues of semicolon insertion are highly debatable, developers are permitted by the ECMAScript standard to write code that relies on it. A tool like JSMin should be aware of semicolon insertion. ricardobeat put it very well elsewhere in this thread: "It is a bug on JSMin. Minifying should never alter code behaviour."
Like I said, there are many, many libraries that don't use them.
I used to prefer having semicolons in my javascript, then I started writing a bunch of Go. Now I wind up forgetting sometimes, though some part of me likes it, and so I continue using semicolons in my javascript.
That having been said, I think it's a matter of personal opinion (likely just what a given person is used to), and if it fits with the spec and the common usage, then you'd think a library that is expected to work with/on other libraries would try to be accommodating.
edit: To further clarify, Javascript's stance is silly, because you need to know how semicolon insertion works. It's extra knowledge you have to have. Thus, I think I agree with most here that it's easier to just use them. (Other languages have optional semicolons but they don't change the meaning of the syntax at all.)
edit2: This is GitHub, why is there not a fork already with this issue behind us?
What a child... Has anyone read the GitHub style guide? 'Do your best to never use a semicolon. This means avoiding them at line breaks and avoiding multi-statement lines.'
Grow up Crockford. Do research before you post. Stop assuming because you supposedly once knew how to do something, you still do, and always will. Times change.
However, this is all very exciting. It gives Twitter, or whatever other start up, an opportunity to replace an outdated piece of software by a nut case!
Why do you believe the github style guide to be the authoritative source for JavaScript style? There is no benefit for avoiding use of semicolons other than not writing semicolons, whereas there are several detriments for their omission.
> It gives Twitter, or whatever other start up, an opportunity to replace an outdated piece of software by a nut case!
I don't know where this ad-hominem is coming from, but Douglas Crockford is hardly a nutcase.
If people hate semi-colons with such a passion, why not simply use coffeescript and be done with it instead of depending on butterflies flapping their wings...
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.