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.
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?
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.
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.
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.
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.
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?
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.
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.
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.
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.
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?
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.
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.
... 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?
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?
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!
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.
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 -.-)
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.
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.
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.
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.
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.
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
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 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.
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.
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.
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...
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.
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.
>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.
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.
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.
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.
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.
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.
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.
ASM in LoseThos is processed with Lex() so <CR> is ignored, mostly. The ASM syntax has been adapted accordingly.
At the command line, an ending ';' is converted to two ;;. The compiler fetches the token ahead so compilation lags a token.
God says...
C:\LoseThos\www.losethos.com\text\PARADISE.TXT
nflames the air;
So started up in his own shape the Fiend.
Back stept those two fair Angels, half amazed
So sudden to behold the grisly king;
Yet thus, unmoved with fear, accost him soon.
Which of those rebel Spirits adjudged to Hell
Comest thou, escaped thy prison? and, transformed,
Why sat'st thou like an enemy in wait,
Here watching at the head of these that sleep?
Know ye not then said Satan, filled with scorn,
Know ye not me? ye knew me once no mate
For you, there sitting where ye durst not
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.
Wow, I had no idea "asi" (automatic semicolon insertion) was a thing. Describing it as "hipster" is pretty much spot on (IMHO).
I think this makes a great negative filter for interviewing actually:
Q: How do you feel about using line-breaks and other obscure JS rules to avoid putting in semi-colons?
A1: That's idiotic (interview progresses)
A2: Great idea (rejected)
That may sound harsh but here's my complaint: working with other programmers means writing code that's easily understood. Syntactic tricks to reduce the character count for a couple of dozen as an artificial barrier to entry shows me that you are far more concerned with mental masturbation and "Javascript elitism" than the needs of the project or your coworkers. Bad culture fit.
User fat ("Jacob") is a perfect example of this.
Crockford could've handled this better but honestly I sympathize with his frustration. Just because something is possible doesn't make it a good idea. You can technically drive a car with no seat belt using nothing but your feet but that doesn't mean you should.
At the end of the day this is a bug in JSMin but how much exactly should one cater for pathological edge cases (which I consider this to be)?
It's all about readability. Sometimes you put parentheses around arithmetic expression to make it clear what's happening, not because it's required. You put a semi-colon after each statement because it's clear.
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.
223 comments
[ 3.0 ms ] story [ 160 ms ] threadThat'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.
In this case, the minifier is breaking the code, regardless.
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.
Great idea! I propose some additional strategies for pruning the contributor pool:
- All numbers in hexadecimal (every idiot knows decimal!)
- No strict equality tests (too easy to reason about & uses extra character!)
- Variable names must consist entirely of unicode ideographs (even my grandmother knows ASCII!)
That should keep the idiots at bay!
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ~Martin Fowler
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 :).
Similarly, using semicolons to end lines means I am saying loud and clear... this line of code ends HERE.
Obviousness is a good thing, no?
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:
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 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.
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?
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 whole thread is arguing about style, IMO. I'm just offering my explanation why this style makes more sense to 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.
Are there compressors that use the syntax tree rather than transforming the source?
Personally, I agree with Crockford -- it's dumb.
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.
CoffeeScript removes semicolons from CoffeeScript, not JavaScript.
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.
They just disagree on whether a semicolon gets inserted here.
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?
Which is why there is a line break there. He's far too stubborn to realize that JSMin is at fault for not being able to correctly parse JavaScript.
Ideally, your goal as a hacker is to make cool shit. Your goal is not syntax.
Simplicity should win; but alas, being one of the cool kids is more important.
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.
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?
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
This unfortunate behavior is well described by Wadler's Law:
http://www.haskell.org/haskellwiki/Wadlers_Law
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.
The infix “!” operator: An eventual analog of “.“, for making eventual requests look more like immediate requests.
[1]: http://wiki.ecmascript.org/doku.php?id=strawman:strawman [2]: http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
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.
It's one thing to insert semicolons in this case:
and another to do so in this kind of case: 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.
Do you see what I'm getting at here?
[1] 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.
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.
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.
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
Arguing about future version of the spec is silly. For all we know the next Javascript spec turns it into a Lisp, and 100% of existing code is broken.
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.
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 disturbing thing is the idiot arguing about implicit semicolons in a language with not good support for them, in a general use library.
http://brendaneich.com/2012/04/the-infernal-semicolon/
The time is ripe for Dart!
edit: now that I said that, it makes a lot of sense.
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.
"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.
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.
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.
Get over it...
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.
At the command line, an ending ';' is converted to two ;;. The compiler fetches the token ahead so compilation lags a token.
God says... C:\LoseThos\www.losethos.com\text\PARADISE.TXT
nflames the air; So started up in his own shape the Fiend. Back stept those two fair Angels, half amazed So sudden to behold the grisly king; Yet thus, unmoved with fear, accost him soon. Which of those rebel Spirits adjudged to Hell Comest thou, escaped thy prison? and, transformed, Why sat'st thou like an enemy in wait, Here watching at the head of these that sleep? Know ye not then said Satan, filled with scorn, Know ye not me? ye knew me once no mate For you, there sitting where ye durst not
It doesn't take a lot more effort to rephrase fat's response to be more cordial.
Flamewar avoided (probably) and more stuff getting done.And if you don't use semicolons you are an asshole.
I think this makes a great negative filter for interviewing actually:
Q: How do you feel about using line-breaks and other obscure JS rules to avoid putting in semi-colons?
A1: That's idiotic (interview progresses)
A2: Great idea (rejected)
That may sound harsh but here's my complaint: working with other programmers means writing code that's easily understood. Syntactic tricks to reduce the character count for a couple of dozen as an artificial barrier to entry shows me that you are far more concerned with mental masturbation and "Javascript elitism" than the needs of the project or your coworkers. Bad culture fit.
User fat ("Jacob") is a perfect example of this.
Crockford could've handled this better but honestly I sympathize with his frustration. Just because something is possible doesn't make it a good idea. You can technically drive a car with no seat belt using nothing but your feet but that doesn't mean you should.
At the end of the day this is a bug in JSMin but how much exactly should one cater for pathological edge cases (which I consider this to be)?
It's all about readability. Sometimes you put parentheses around arithmetic expression to make it clear what's happening, not because it's required. You put a semi-colon after each statement because it's clear.