81–90 of 224 posts
> ! is not intended to be a statement separator. ; is. 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.
The line break will not help if ! becomes an infix operator.
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…
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…
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…
Edit: rm js rant
Earlier quoted context omitted.
[deleted]
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. [1]:…
Earlier quoted context omitted.
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, bu…
[deleted]
It's one thing to insert semicolons in this case:
Another distinctive feature of Algol-derived languages is that two adjacent expressions are generally not meaningful; for example, 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 \n 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.
Earlier quoted context omitted.
So in this case: var value = x + fn (y).burp() 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…
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.
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?
Earlier quoted context omitted.
[deleted]
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: 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…
And if you don't use semicolons you are an asshole.