14 ms·

Of parser-fetishists and semi-colons

153 points by Isofarro 15y ago

mikeryan 15y ago
This whole debate seems like two folks stuck in their way blowing a whole thing out of proportion. How about Bootstrap adds the damn semi-colon and JSLint accepts that for the most part the lack of a semi-colon is working and "valid" JS add allows for the edge case. Now everyone gets to go home happy.
- WiseWeasel 15y ago
  Bootstrap and JSMin have both since fixed their code. http://news.ycombinator.com/item?id=3845267 http://news.ycombinator.com/item?id=3845267
Ramone 15y ago
I think the argument that we shouldn't rely on the parser for certain language features is a bit silly (including interpreting end-of-statements). The language is precisely what the parser says it is, and nothing more or less. JSMin is free to not do what the parser does of course, but that won't be Javascript.
- EvilTerran 15y ago
  Surely the language is precisely what the spec says it is? "The parser is the spec" is a nasty design smell, IMO.
  - ktizo 15y ago
    Surely the environment is the spec. If he wants his code to work with this particular minifier, he should include the semicolon, nothing more, nothing less. Is a bit like trying to speak in official french. It might be correct according to the officials charged with protecting the french language, but you will sound extremely odd to most french people.
    - stcredzero 15y ago
      I've heard that in Korea, there's one national standard exam for English that's always been graded incorrectly, so everyone learns the incorrect answer when studying for the test.
  - jmount 15y ago
    Yup- "computer science" is definitely going retrograde. It was recognized a long time ago that the "implementation is the spec" was a disaster for program semantics. And now we have "implementation is the spec" for something as easy and inessential as parsing. 1950s computer science labored under the misapprehension that parsing was hard (FORTRAN contributing greatly to this feeling). Then parsing was solved (while we don't always user machine generated parsers the ability to specify a grammar and see what features make parsing easy versus hard is a huge step forward). In fact this early victory over the formerly hard problem of parsing is one of the reasons people started anticipating higher and higher level languages and the complete automation of programing. But (as Brooks points out in "The Mythical Man Month") parsing was solved precisely because it was an inessential difficulty. Save your mental cycles for essential difficulties (semantics, evolution of state, remote machines, concurrency and actual domain problems).
- wpietri 15y ago
  I'm not sure if you're making that argument yourself, but it's thoroughly wrong. First, there's no "the parser". There are a lot of parsers, some of which don't yet exist. Second, that means there's no way to distinguish between bugs and features. If the language is defined by parser behavior, then any parser bug is now part of the language. Third, you've eliminated the white space needed for future growth. If you look at any standard that has evolved well over a period of years, you can see in the early days there was a lot left undefined. If the implementation is the spec, then nothing can be treated as open for change.
  - blasdel 15y ago
    javascript the language itself has a spec that everyone has pretty much always implemented consistently even in the worst throes of the browser wars (the runtime libraries, not so much) the problem was that jsmin didn't just violate the spec — it's not a javascript implementation at all, but rather a pile of naive textual replacements
bmj1 15y ago
The author is right on the money. I've always written code as specified - just because it felt 'right' - but I could never pin down my arguments - the author captures my thoughts beautifully. Particularly his points about reading other people's code & extending functionality - there are very few use-cases where it makes sense to omit semi-colons, end-tags, etc - and if you aren't sure - yours isn't one of those use-cases.
mike_esspe 15y ago
I suspect, that to understand the logic behind semicolon exclusion, you should program at least a little in the languages, that do not require it. At least for me, mental switch between semicolon and no semicolon is hard for some reason, if it happens a lot during the day :)
- EvilTerran 15y ago
  I leave out semicolons in my Haskell, and my Python. I use them in my JS, because JS's implicit semicolon rules are rubbish compared to any other language that I've tried with such rules. It's kinda presumptuous to assume that people who disagree with you don't "understand the logic behind" your position.
VeejayRampay 15y ago
I think this whole semicolon story is a natural step of a language becoming more wide-spread. The more people spend time appropriating the language, the more they'll want to push the envelope, exploit the quirks and get the best out of the language's syntax. It's a natural cycle. C programmers went through the very same phase at some point and to this day different coding styles persist. It's only when those choices cause incompatibilities that friction emerges, but we should see it as a natural step towards a more unified grasp of what Javascript means for people who program with it. That the general tone of the conversation is antagonistic is just a symptom of the fact that people care about their opinions and their choices, which by all means should be seen as a very healthy questioning on the part of the community. Just my 2 cents. TL;DR: Sure the image conveyed is bad, but the reasons why such a debate emerges are natural and are part of the evolution of a language, it'll get better.
LoonyPandora 15y ago
Now, this could be easily solved – by adding the friggin semicolon. What this furore misses is that the original issue (JSMin failing to minify bootstrap-dropdown.js) was already fixed when the bug was raised [1]. Fixed without adding semicolons. Everyone should be happy with that. Developers of bootstrap got to stick to their "no semicolons" schtick, and the person with the original problem got it fixed. Everyone seems to forget this salient point when they rush in to this debate. For reference, I sometimes use semicolons in my javascript, sometimes I don't. It depends on context and whether it makes the code more readable. It's not an issue I care enough about to get involved in a holy war, one only marginally more relevant than tabs vs spaces. [1] https://github.com/twitter/bootstrap/issues/3057#issuecomment-5140916 https://github.com/twitter/bootstrap/issues/3057#issuecommen...
- lucisferre 15y ago
  That isn't really the original issue at all, Crockford's comment is just what brought it to a boilover. The lack of semi-colons has been brought up in issue after issue on the bootstrap project. Each time it's been rejected for the same arguably poor reasoning. Christian's post is completely spot on here. Javascript was designed to be tolerant of errors and inconsistencies as much as it could. That fact however, shouldn't be used as an excuse for advocating inconsistent coding. Not that I'm saying semi-colons are the epitome of consistent coding (I prefer Ruby myself) but that Javascript was not designed with significant whitespace in mind, rather it just has a tolerance for inconsistent and arguably erroneous syntax. The argument here is that we shouldn't let Javascript's tolerance excuse laxness on our parts. We should know better.
  - LoonyPandora 15y ago
    By "original issue", I was referring to the actual GitHub issue / bug report. On the wider issue of semicolons I am in agreement of you, and all my own code is written with that in mind - though I respect the bootstrap authors preference and would style my pull requests without semicolons. If their insistence on not using semicolons causes conflict with other popular software, I would hope they see sense and fix those conflicts - even if that meant adding a semicolon or two.
georgieporgie 15y ago
This whole debacle is the epitome of what I call alpha-nerd behavior, and it's slowly killing my interest in software development.
- bmm6o 15y ago
  It's actually quite easy to develop software while being only vaguely aware of and emotionally uninvested in these sorts of kerfuffles.
  - georgieporgie 15y ago
    Well, in nearly every job I've had, there's at least one alpha nerd[1]. Worst of all is the alpha nerd boss (I intentionally avoid the word 'manager' here). I welcome advice on how to find working environments free of this sort of thing. [1] - two or more is even worse: they're like male gerbils or betta fish, in that they fight all the time.
    - arethuza 15y ago
      As a reformed "alpha nerd boss", I suspect most people grow out of it.
ajross 15y ago
I've been shocked at the level of disrespect for language standards here. Yes: adding semicolons is probably good practice because it avoids the chance of stumbling over bugs like this. And yes: the ASI feature in Javascript is in hindsight a terrible mistake. That said: you go to war with the language you have, not the one you might want or wish to have. ECMAScript is ECMAScript. Arguing that your transformation tool doesn't need to handle a feature specified in the language and supported by all known implementations is just ridiculous. Arguing that people making use of a feature that the language standard says they can (and that works) are "sloppy" is equally dumb. Even weirder are the people who jumped on the use of the && operator to effect an "if" as "abuse" -- this is an idiom pervasive in lots of areas and (again) well-supported by Javascript. Not everyone is going to have the same aesthetics, everyone has a different idea about what features are "fun" and which are "sloppy". And decades of experience in the "code convention hell" world of enterprise programming has taught us nothing if not that this sort of pedantry helps no one. If you want to use Javascript, you have to take the whole language -- warts and all.
- courtewing 15y ago
  I agree with you to a certain extent, but I do think it is important to distinguish between those that think that they should just use a semi-colon and those that seek to disrespect a standard. In my case, and I've seen this sentiment expressed repeatedly by others on HN, I think it is odd that a minification script would actively choose not to support a syntax that is standards compliant. On the other hand, I think it is crazy for a major project to use a valid syntax that not only breaks said [popular] minifier but also offers no noticeable benefit. I do not feel as if I'm disrespecting any standard just because I think simply adhering to that standard is not a sufficient justification for doing something.
  - ajross 15y ago
    But "no noticeable benefit" is your aesthetic decision, not an objective truth. Not everyone feels the same. Pythonistas, for example, might quibble with you about that, because they skip semis when typing all the time and will experience editor friction when using Javascript. And even if you think it's "crazy" to skip the semicolons, you might not think it's crazy to write something like "test && result" as a simple if. Shell and perl programmers like that sort of thing and can read it without difficulty. I'm not saying that all working code is good code, or that you have to actually use all the language features in all your code, or that you can't have your own well-reasoned opinions about this stuff. What I am saying is that if you're serious about using "Javascript" and interacting with the broader community of "Javascript" programmers, this kind of feature pedantry is going to hurt you and the community badly. You will constantly be running into useful (maybe even brilliant) code that does "crazy" things.
tptacek 15y ago
Anyone else think this is by far the most boring technical debate ever to hit HN?
- slantyyz 15y ago
  Agreed! It amazes me how much time people have spent arguing over this. When I see an open source library that's not coded in the way I like, I either customize it to my liking or look for alternatives. The only time I would really care about someone's programming style is when I work with them, otherwise live and let live.
  - fusiongyro 15y ago
    It would be that way, but for the fact that this style breaks other tooling.
- lifeformed 15y ago
  It seems more like a social interaction issue than a technical one.
  - deleted 15y ago
    [deleted]
  - gruseom 15y ago
    Bingo. I'm sure the same was true of angels dancing on the head of a pin. Edit: the point is that sometimes arguments seem stupid because we don't always say (or even know) what we really care about.
    - arethuza 15y ago
      If there had been software development a thousand years ago we'd be burning people for using (or not using) tabs/semicolons/emacs etc.
- sophacles 15y ago
  Of the sustained debates, I feel it is tied with the "my nosql is better than yours" debate. Both of them seem to boil down to "understand your tools, your use case may not map to the thing someone else is advocating for their use case".
raverbashing 15y ago
Add the semicolon "but but but" add the semicolon There's so much FOR it, it's unbelievable. Yes, it's good to 'break the rules' now and then. Add the semicolon This is not about if JS allows it or not. It's important, but mostly irrelevant. You can also not add 'var' to JS variables unless needed. That's going to be a lot of fun when it goes wrong. But here are the million dollar questions: 1 - How much time is spent making it work without a semicolon as opposed to just typing it? This is not about typing ';' - time for that is irrelevant, but the mental effort of doing so 2 - How much time will it be wasted to fix minifiers (that is, add to them the intricacies of no-semi colon parsing and probably having to write a whole different parser) 3 - How much mental effort is needed to comprehend and correctly fix non semicolon code Number 3 is the biggest issue and if you don't believe me it goes by another name: coding standard Yes, JS works without semicolons. And yes, C works without indenting, without meaningful names to variables, etc. It's not about "to write JS you should know all the nitty-gritty rules of the language and you're stupid if you don't know them so you just add semicolons". It's about teamwork, and facilitating code comprehension (and maintenance). And language designers make mistakes. They don't know if a feature is going to become a trap, irrelevant to 99% of developers (and with an easy workaround) or just a pain in the behind.
- stonemetal 15y ago
  As a devils advocate. 1. How many times are we going to have to debug and rewrite code to work around this defect? If it were just this once sure add the the ';', unfortunately it is never just this once. 2. How much time will be saved by using a minifier that actually supports the javascript language. What other language features will break because someone didn't feel like supporting javascript in their javascript minifier? 3. How much mental effort is needed to support half a dozen different minifiers that all support a different subset of the language as well as the cross browser differences we already have to take into account. It is a matter of trust. If your tools skip supporting language features because someone decided they didn't like language feature X, what other corner cases did they skip because they were unliked?
  - stcredzero 15y ago
ehutch79 15y ago
All the people arguing that the code as was presented should is good and right, I present this: Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it? ~Brian Kernighan I couldn't tell that the second line in the code in question was an if statement at first without actually thinking about it. How is that helpful?
- lowboy 15y ago
  I imagine you would get used to viewing that statement as a conditional. Hell, I think most people involved with this debate would recognize it now.
h2s 15y ago
Haven't yet seen anyone point out what unpleasantly quirky code this was in the first place: !isActive && $parent.toggleClass('open') It should have been written like this: if (!isActive) { $parent.toggleClass('open'); } What if somebody needs to add a second bit of code to be executed if isActive is false? In the first case, they'd have to refactor the code into an if statement before adding it. It should have been an if statement in the first place. If you want something to happen if something is true, then you should use an if statement. This is not controversial stuff. Don't look for "clever" ways to misappropriate other parts of the syntax in order to appeal to your own personal minimalist aesthetic taste. Be cooperative. Edit: On re-reading this it comes off as preachy. In fact I've very recently taken a closer look at some of my own "little quirks" and realised how unhelpful they were for other developers. I guess I'm embarrassed about that and want to spread the embarrassment around.
- miahi 15y ago
  You can always continue with !isActive && ($parent.toggleClass('open') || do_something_else()) but this is write-only code. This actually reminds me of some cool hacks with structure pointers and functions in the Linux kernel.
  - luser001 15y ago
    Unless I'm mistaken 'do_something_else()' won't get executed if toggleClass() returns a value that evaluates to true. Because of short-circuit boolean evaluation.
    - philipjrose 15y ago
      That's correct. You could use: !isActive && ($parent.toggleClass('open'), do_something_else()) but I don't think anyone would advise it.
      - chris_wot 15y ago
        Actually, you are all missing Crockford's real point, which is that they are considering making ! a binding deference of function objects. If they do, then this: clearMenus() !isActive && $parent.toggleClass('open') Becomes this: clearMenus()!isActive && $parent.toggleClass('open'); And not this: clearMenus(); !isActive && $parent.toggleClass('open'); The no semi-colon crowd is ridiculous. There are no good arguments for omitting semicolons!
latortuga 15y ago
I have grown extremely weary at the level of discourse that this whole situation has provoked - the linked post is one ad hominem after another! What is this supposed to accomplish? Hopefully I can get the people I'm criticizing to change their ways by making them feel really bad about themselves? By telling them they aren't visionaries, they are semi-colons, they are arrogant, sloppy, lazy? It's destructive, self-indulgent, and completely unnecessary.
- whateverer 15y ago
  I upvoted you. This whole semicolon war is the most banal and self-aggrandizing conflict I've seen in a while, rife with as much vanity and childishness a the ``blogosphere'' allows, as evidenced by this post. Can we move on, please? At least everyone acknowledged that the editor war was an inside joke, I would gladly have an editor thread every week on HN over this.
ExpiredLink 15y ago
> The main issue with these parser-fetish arguments is that they assume that you write code for a parser – sometimes even a certain browser – and not for other developers. That's an excellent and important point beyond the petty incident. You write code solely for humans, not for the compiler.
n_time 15y ago
To me this argument boils down to style over maintainability. The arguments for the latter seem so clear in my mind that I don't really want to dignify the other side with a response.
LeafStorm 15y ago
I come from a Python background. However, thanks to work and school, I now program mostly in JavaScript, PHP, and Java (though I still use Python when I get a chance). Now, I could use underscore_names in Java and JavaScript, but I don't. Even though I personally prefer underscore_names to camelCaseNames, I also realize that those languages are designed with camelCaseNames in mind, that the community conventions are for camelCaseNames, and that it is better to write code that looks nice and idiomatic in that language than it is to write code that looks nice and idiomatic in Python. Not to mention that there are some cases where camelCaseNames are required - for example, when overriding inherited methods in Java - and if I used camelCase where required and underscore_names everywhere else, my code would be inconsistent, which to me is worse than using a style I don't like. So just because I could use underscore_names when I wanted to, there are a lot of reasons that I shouldn't. A lot of those points also apply to JavaScript: * JavaScript was designed with the use of semicolons in mind. Brandon Eich himself has said that ASI was only intended as an extra check for sloppy programmers. * Outside the Ruby on Rails crowd, all the JavaScript I have ever seen uses semicolons. Even within the Rails crowd, this "no semicolons" thing is fairly recent. * Since the majority of JavaScript syntax is intended to mimic Java syntax, which does require semicolons to separate statements, semicolons blend well with the language, and are therefore nice and idiomatic. * There are situations where you have to use semicolons due to ambiguity to write straightforward code - there are workarounds, like tricks involving !, but they confuse the intent of the code. One thing that I noticed is that most of the notable semicolon-haters - fat, mislav, and the GitHub guys - come from Ruby on Rails. Conveniently enough, Ruby does not require semicolons at the end of statements. I suspect this anti-semicolon fervor may come from a desire to use Ruby's conventions with JavaScript.
- jrockway 15y ago
  Incidentally, we use CamelCaseMethodNames in Python at Google, presumably to be consistent between languages. If you're one company that uses multiple languages, it may be beneficial to use the same style in each, even if that style is non-idiomatic.
  - frio 15y ago
benatkin 15y ago
The author is picking and choosing who he wants in this argument of his. He has Douglas Crockford and Brendan Eich on the pro-trailing-semicolon side. On the other side he has @fat. If he wanted to be fair he could have included someone like @izs or Thomas Fuchs. But if he referenced their viewpoints on it, it would make it harder to pretend that all code that doesn't include trailing semicolons after every statement is brittle.
- Isofarro 15y ago
  "He has Douglas Crockford and Brendan Eich on the pro-trailing-semicolon side" Brendan Eich, the conceiver of the language. The best placed person in understanding why the JavaScript language does what it does, and what problem a feature was trying to solve. Douglas Crockford, the developer who took all of JavaScript and found within a clean elegant language. And then he pulled together what he considered the best bits of the language and used that subset as a starting point. http://anongallery.org/220/javascript-the-good-parts http://anongallery.org/220/javascript-the-good-parts @fat - no idea who he is, apart from being an employee of Twitter and works on Twitter Bootcamp, which is a framework for other people to use to build websites. @izs - I think you overreach by grouping him as anti-semi-colon. Isaac is a pragmatist, he uses what suits the group of people he works with. NPM is a standalone app, a non-expert JavaScript developer doesn't need to delve into npm for it's standard usecases. So he choses a syntax he believes suits the group of people working with him. And yet, he is now the lead developer of Node.js, and he's already on record saying he won't be spending time changing Node.js into his preferred comma prefixed approach - because the existing team is already used to post fixed commas. That's what I like about Isaac - he listens to a wide range of opinions, and uses what works best for the environment he's in. Thomas Fuchs - heard of him, he's done lots of stuff JavaScript and PHP wise. I'll give you that one. He gave us Scriptaculous, and some decent PHP resources (like PHPatterns, IIRC). He's active in Rails. The main reason the quality of JavaScript has increased dramatically in the last 6 or 7 years has been because of a coalescing towards a JavaScript best practice. This has mainly been led by Douglas Crockford and JavaScript developers at Yahoo. JavaScript is too flexible and too bastardised a language, leaving lots of weird and broken features. Plus, well written code isn't about being clever, it's about writing code that can be supported and maintained. Douglas has taken the best bits of JavaScript and found that to be quite an effective and useful language. With that subset he, along with the people who later became the YUI library developers wrote code in that subset. The reason for that subset is that the language is clearer, less ambiguous, and less likely to catch a developer out. Turns out using just a subset of JavaScript's syntactic capabilities improves the quality, reliability and maintainability of code. JS Lint was build to help developers bring their code into line with this subset of usage, and disallow perfectly valid but potentially flawed code. It favours code that is readable and quickly understandable by the non-expert developer. JS Lint is the starting point for this improved use of JavaScript. JS Min is built, as far as I understand, with the assumption that JSLint rules are in place, so yes, it works on a subset of the language. Actually the documentation http://www.crockford.com/javascript/jsmin.html http://www.crockford.com/javascript/jsmin.html is more specific: "It is suggested that JSLint be used before using JSMin." And I guess that's the real problem here. Not using JSLint before using JSMin. And then this argument boils down to @fat saying something along the lines of not wanting to be constrained to JSLint's subset of JavaScript. That's a call he can make, and the users of Twitter Bootcamp can then choose accordingly whether to use the toolkit (since if you are in a JSLint / JSMin using environment, it's probably best to stay away from Twitter Bootcamp.) Perhaps what would be worthwhile is a JSLint equivalent for whatever syntax and idioms the Rails-induced subset of JavaScript uses (not just a watered down version of JSLint that JSHint is, but something that encourages what they consider to be best practice rather than merely allow it), and a minified that respects those idioms. And something in plain English for those unfortunate developers who stumble into these idioms. What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?
stiff 15y ago
I think the real issue in the whole debate is that 95%+ of people programming do not understand how programming languages are implemented and haven't been exposed to basic theoretical stuff e. g. to the fact that languages can be ambiguous, that there are cases where it might be impossible to interpret a part of the code, that handling syntax errors is actually hard etc. This post is a good example, it completely misses the point, as the only reason semicolons are present in some languages is to make parsing possible. I think many people would not argue about this if they had a clue why programming languages syntax is the way it is.
Tichy 15y ago
Somebody should do a HN poll. I bet it was already done, but I am too lazy to search for it.
stcredzero 15y ago
tldr from the article: So, if your code needs syntactical changing when it gets extended, to me you’ve optimized prematurely. Code will always change and making sure our maintainers have a hard time breaking it is a very simple and good idea. In other words, a good programmer writes code for project maintainability, not to signal dominance by showing off knowledge of the parser. [+] (Corollary: One's cleverness is always a finite resource. I'd rather work with someone who devotes that resource to what's good for the project, not his own fame and ego.) [+] - Unfortunately, the way teaching CS sometimes works, students are rewarded for showing off clever and elite code every chance they get, to show the prof they're a "real" coder.
bitwize 15y ago
Every programmer should have had a professor who was really, inordinately fond of Ada, so much so that at least one assignment required coding in, or basic knowledge of, the language. Ada is strict as balls, but unlike its wannabe-successor, C++, its strictness is for the sake of clairty and the compiler usually actively helps you bring your code into compliance. (Rather than, say, complaining randomly because the syntax for template instantiations changed this week, or punishing you for pronouncing the word "const" with the improper intonation.) With a bit of exposure to Ada, programmers might understand better why languages are so finicky about syntax details, and that just because a language is lenient, doesn't mean you should take advantage of that leniency. And that, in cases like JavaScript with its bloody semicolons, perhaps leniency is a disadvantage.
- rblatz 15y ago
  I had a professor like that, he also was a signatory to the original ECMAscript standard. He also claims he came up with that name. Since they were spending too much time debating the name, he figured they'd call it that for now, and since it was such an awful name they would be sure to go back and change it.
buster 15y ago
Reminds me how learning python took all the fun out of those semicolon and curlybraces loving languages. Americans (with US keyboards) really shouldn't design a programming language nowadays.
lucian303 15y ago
This is ridiculous. Twitter's developers are lazy. You don't NEED a semicolon for the interpreter, you NEED a semicolon for the other readers/users of your code!!! That goes for all other code practices that enhance readability. If you disagree that human readability is less important than interpreter/compiler, you're a lazy moron. Period.
chaostheory 15y ago
This argument is pointless. At the end of the day, the current owner of Bootstrap can do whatever he wants. If the semi-colon issue is that important, people should just fork the project and add semi-colons.
agranig 15y ago
Writing great code means making it easily readable and understandable by other developers. If you want to show off your quirky syntax skills, for god's sake play perl golf or attend at obfuscated code contests.

153 points by Isofarro 15y ago

This whole debate seems like two folks stuck in their way blowing a whole thing out of proportion. How about Bootstrap adds the damn semi-colon and JSLint accepts that for the most part the lack of a semi-colon is working and "valid" JS add allows for the edge case. Now everyone gets to go home happy.

WiseWeasel 15y ago
Bootstrap and JSMin have both since fixed their code. http://news.ycombinator.com/item?id=3845267 http://news.ycombinator.com/item?id=3845267

Ramone 15y ago

I think the argument that we shouldn't rely on the parser for certain language features is a bit silly (including interpreting end-of-statements). The language is precisely what the parser says it is, and nothing more or less. JSMin is free to not do what the parser does of course, but that won't be Javascript.

EvilTerran 15y ago
Surely the language is precisely what the spec says it is? "The parser is the spec" is a nasty design smell, IMO.
- ktizo 15y ago
  Surely the environment is the spec. If he wants his code to work with this particular minifier, he should include the semicolon, nothing more, nothing less. Is a bit like trying to speak in official french. It might be correct according to the officials charged with protecting the french language, but you will sound extremely odd to most french people.
  - stcredzero 15y ago
    I've heard that in Korea, there's one national standard exam for English that's always been graded incorrectly, so everyone learns the incorrect answer when studying for the test.
- jmount 15y ago
  Yup- "computer science" is definitely going retrograde. It was recognized a long time ago that the "implementation is the spec" was a disaster for program semantics. And now we have "implementation is the spec" for something as easy and inessential as parsing. 1950s computer science labored under the misapprehension that parsing was hard (FORTRAN contributing greatly to this feeling). Then parsing was solved (while we don't always user machine generated parsers the ability to specify a grammar and see what features make parsing easy versus hard is a huge step forward). In fact this early victory over the formerly hard problem of parsing is one of the reasons people started anticipating higher and higher level languages and the complete automation of programing. But (as Brooks points out in "The Mythical Man Month") parsing was solved precisely because it was an inessential difficulty. Save your mental cycles for essential difficulties (semantics, evolution of state, remote machines, concurrency and actual domain problems).
wpietri 15y ago
I'm not sure if you're making that argument yourself, but it's thoroughly wrong. First, there's no "the parser". There are a lot of parsers, some of which don't yet exist. Second, that means there's no way to distinguish between bugs and features. If the language is defined by parser behavior, then any parser bug is now part of the language. Third, you've eliminated the white space needed for future growth. If you look at any standard that has evolved well over a period of years, you can see in the early days there was a lot left undefined. If the implementation is the spec, then nothing can be treated as open for change.
- blasdel 15y ago
  javascript the language itself has a spec that everyone has pretty much always implemented consistently even in the worst throes of the browser wars (the runtime libraries, not so much) the problem was that jsmin didn't just violate the spec — it's not a javascript implementation at all, but rather a pile of naive textual replacements

bmj1 15y ago

The author is right on the money. I've always written code as specified - just because it felt 'right' - but I could never pin down my arguments - the author captures my thoughts beautifully. Particularly his points about reading other people's code & extending functionality - there are very few use-cases where it makes sense to omit semi-colons, end-tags, etc - and if you aren't sure - yours isn't one of those use-cases.

mike_esspe 15y ago

I suspect, that to understand the logic behind semicolon exclusion, you should program at least a little in the languages, that do not require it. At least for me, mental switch between semicolon and no semicolon is hard for some reason, if it happens a lot during the day :)

EvilTerran 15y ago
I leave out semicolons in my Haskell, and my Python. I use them in my JS, because JS's implicit semicolon rules are rubbish compared to any other language that I've tried with such rules. It's kinda presumptuous to assume that people who disagree with you don't "understand the logic behind" your position.

VeejayRampay 15y ago

I think this whole semicolon story is a natural step of a language becoming more wide-spread. The more people spend time appropriating the language, the more they'll want to push the envelope, exploit the quirks and get the best out of the language's syntax. It's a natural cycle. C programmers went through the very same phase at some point and to this day different coding styles persist. It's only when those choices cause incompatibilities that friction emerges, but we should see it as a natural step towards a more unified grasp of what Javascript means for people who program with it. That the general tone of the conversation is antagonistic is just a symptom of the fact that people care about their opinions and their choices, which by all means should be seen as a very healthy questioning on the part of the community. Just my 2 cents. TL;DR: Sure the image conveyed is bad, but the reasons why such a debate emerges are natural and are part of the evolution of a language, it'll get better.

LoonyPandora 15y ago

Now, this could be easily solved – by adding the friggin semicolon. What this furore misses is that the original issue (JSMin failing to minify bootstrap-dropdown.js) was already fixed when the bug was raised [1]. Fixed without adding semicolons. Everyone should be happy with that. Developers of bootstrap got to stick to their "no semicolons" schtick, and the person with the original problem got it fixed. Everyone seems to forget this salient point when they rush in to this debate. For reference, I sometimes use semicolons in my javascript, sometimes I don't. It depends on context and whether it makes the code more readable. It's not an issue I care enough about to get involved in a holy war, one only marginally more relevant than tabs vs spaces. [1] https://github.com/twitter/bootstrap/issues/3057#issuecomment-5140916 https://github.com/twitter/bootstrap/issues/3057#issuecommen...

lucisferre 15y ago
That isn't really the original issue at all, Crockford's comment is just what brought it to a boilover. The lack of semi-colons has been brought up in issue after issue on the bootstrap project. Each time it's been rejected for the same arguably poor reasoning. Christian's post is completely spot on here. Javascript was designed to be tolerant of errors and inconsistencies as much as it could. That fact however, shouldn't be used as an excuse for advocating inconsistent coding. Not that I'm saying semi-colons are the epitome of consistent coding (I prefer Ruby myself) but that Javascript was not designed with significant whitespace in mind, rather it just has a tolerance for inconsistent and arguably erroneous syntax. The argument here is that we shouldn't let Javascript's tolerance excuse laxness on our parts. We should know better.
- LoonyPandora 15y ago
  By "original issue", I was referring to the actual GitHub issue / bug report. On the wider issue of semicolons I am in agreement of you, and all my own code is written with that in mind - though I respect the bootstrap authors preference and would style my pull requests without semicolons. If their insistence on not using semicolons causes conflict with other popular software, I would hope they see sense and fix those conflicts - even if that meant adding a semicolon or two.

georgieporgie 15y ago

This whole debacle is the epitome of what I call alpha-nerd behavior, and it's slowly killing my interest in software development.

bmm6o 15y ago
It's actually quite easy to develop software while being only vaguely aware of and emotionally uninvested in these sorts of kerfuffles.
- georgieporgie 15y ago
  Well, in nearly every job I've had, there's at least one alpha nerd[1]. Worst of all is the alpha nerd boss (I intentionally avoid the word 'manager' here). I welcome advice on how to find working environments free of this sort of thing. [1] - two or more is even worse: they're like male gerbils or betta fish, in that they fight all the time.
  - arethuza 15y ago
    As a reformed "alpha nerd boss", I suspect most people grow out of it.

ajross 15y ago

I've been shocked at the level of disrespect for language standards here. Yes: adding semicolons is probably good practice because it avoids the chance of stumbling over bugs like this. And yes: the ASI feature in Javascript is in hindsight a terrible mistake. That said: you go to war with the language you have, not the one you might want or wish to have. ECMAScript is ECMAScript. Arguing that your transformation tool doesn't need to handle a feature specified in the language and supported by all known implementations is just ridiculous. Arguing that people making use of a feature that the language standard says they can (and that works) are "sloppy" is equally dumb. Even weirder are the people who jumped on the use of the && operator to effect an "if" as "abuse" -- this is an idiom pervasive in lots of areas and (again) well-supported by Javascript. Not everyone is going to have the same aesthetics, everyone has a different idea about what features are "fun" and which are "sloppy". And decades of experience in the "code convention hell" world of enterprise programming has taught us nothing if not that this sort of pedantry helps no one. If you want to use Javascript, you have to take the whole language -- warts and all.

courtewing 15y ago
I agree with you to a certain extent, but I do think it is important to distinguish between those that think that they should just use a semi-colon and those that seek to disrespect a standard. In my case, and I've seen this sentiment expressed repeatedly by others on HN, I think it is odd that a minification script would actively choose not to support a syntax that is standards compliant. On the other hand, I think it is crazy for a major project to use a valid syntax that not only breaks said [popular] minifier but also offers no noticeable benefit. I do not feel as if I'm disrespecting any standard just because I think simply adhering to that standard is not a sufficient justification for doing something.
- ajross 15y ago
  But "no noticeable benefit" is your aesthetic decision, not an objective truth. Not everyone feels the same. Pythonistas, for example, might quibble with you about that, because they skip semis when typing all the time and will experience editor friction when using Javascript. And even if you think it's "crazy" to skip the semicolons, you might not think it's crazy to write something like "test && result" as a simple if. Shell and perl programmers like that sort of thing and can read it without difficulty. I'm not saying that all working code is good code, or that you have to actually use all the language features in all your code, or that you can't have your own well-reasoned opinions about this stuff. What I am saying is that if you're serious about using "Javascript" and interacting with the broader community of "Javascript" programmers, this kind of feature pedantry is going to hurt you and the community badly. You will constantly be running into useful (maybe even brilliant) code that does "crazy" things.

tptacek 15y ago

Anyone else think this is by far the most boring technical debate ever to hit HN?

slantyyz 15y ago
Agreed! It amazes me how much time people have spent arguing over this. When I see an open source library that's not coded in the way I like, I either customize it to my liking or look for alternatives. The only time I would really care about someone's programming style is when I work with them, otherwise live and let live.
- fusiongyro 15y ago
  It would be that way, but for the fact that this style breaks other tooling.
lifeformed 15y ago
It seems more like a social interaction issue than a technical one.
- deleted 15y ago
  [deleted]
- gruseom 15y ago
  Bingo. I'm sure the same was true of angels dancing on the head of a pin. Edit: the point is that sometimes arguments seem stupid because we don't always say (or even know) what we really care about.
  - arethuza 15y ago
    If there had been software development a thousand years ago we'd be burning people for using (or not using) tabs/semicolons/emacs etc.
sophacles 15y ago
Of the sustained debates, I feel it is tied with the "my nosql is better than yours" debate. Both of them seem to boil down to "understand your tools, your use case may not map to the thing someone else is advocating for their use case".

raverbashing 15y ago

Add the semicolon "but but but" add the semicolon There's so much FOR it, it's unbelievable. Yes, it's good to 'break the rules' now and then. Add the semicolon This is not about if JS allows it or not. It's important, but mostly irrelevant. You can also not add 'var' to JS variables unless needed. That's going to be a lot of fun when it goes wrong. But here are the million dollar questions: 1 - How much time is spent making it work without a semicolon as opposed to just typing it? This is not about typing ';' - time for that is irrelevant, but the mental effort of doing so 2 - How much time will it be wasted to fix minifiers (that is, add to them the intricacies of no-semi colon parsing and probably having to write a whole different parser) 3 - How much mental effort is needed to comprehend and correctly fix non semicolon code Number 3 is the biggest issue and if you don't believe me it goes by another name: coding standard Yes, JS works without semicolons. And yes, C works without indenting, without meaningful names to variables, etc. It's not about "to write JS you should know all the nitty-gritty rules of the language and you're stupid if you don't know them so you just add semicolons". It's about teamwork, and facilitating code comprehension (and maintenance). And language designers make mistakes. They don't know if a feature is going to become a trap, irrelevant to 99% of developers (and with an easy workaround) or just a pain in the behind.

stonemetal 15y ago
As a devils advocate. 1. How many times are we going to have to debug and rewrite code to work around this defect? If it were just this once sure add the the ';', unfortunately it is never just this once. 2. How much time will be saved by using a minifier that actually supports the javascript language. What other language features will break because someone didn't feel like supporting javascript in their javascript minifier? 3. How much mental effort is needed to support half a dozen different minifiers that all support a different subset of the language as well as the cross browser differences we already have to take into account. It is a matter of trust. If your tools skip supporting language features because someone decided they didn't like language feature X, what other corner cases did they skip because they were unliked?
- stcredzero 15y ago

ehutch79 15y ago

All the people arguing that the code as was presented should is good and right, I present this: Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it? ~Brian Kernighan I couldn't tell that the second line in the code in question was an if statement at first without actually thinking about it. How is that helpful?

lowboy 15y ago
I imagine you would get used to viewing that statement as a conditional. Hell, I think most people involved with this debate would recognize it now.

h2s 15y ago

Haven't yet seen anyone point out what unpleasantly quirky code this was in the first place: !isActive && $parent.toggleClass('open') It should have been written like this: if (!isActive) { $parent.toggleClass('open'); } What if somebody needs to add a second bit of code to be executed if isActive is false? In the first case, they'd have to refactor the code into an if statement before adding it. It should have been an if statement in the first place. If you want something to happen if something is true, then you should use an if statement. This is not controversial stuff. Don't look for "clever" ways to misappropriate other parts of the syntax in order to appeal to your own personal minimalist aesthetic taste. Be cooperative. Edit: On re-reading this it comes off as preachy. In fact I've very recently taken a closer look at some of my own "little quirks" and realised how unhelpful they were for other developers. I guess I'm embarrassed about that and want to spread the embarrassment around.

miahi 15y ago
You can always continue with !isActive && ($parent.toggleClass('open') || do_something_else()) but this is write-only code. This actually reminds me of some cool hacks with structure pointers and functions in the Linux kernel.
- luser001 15y ago
  Unless I'm mistaken 'do_something_else()' won't get executed if toggleClass() returns a value that evaluates to true. Because of short-circuit boolean evaluation.
  - philipjrose 15y ago
    That's correct. You could use: !isActive && ($parent.toggleClass('open'), do_something_else()) but I don't think anyone would advise it.
    - chris_wot 15y ago
      Actually, you are all missing Crockford's real point, which is that they are considering making ! a binding deference of function objects. If they do, then this: clearMenus() !isActive && $parent.toggleClass('open') Becomes this: clearMenus()!isActive && $parent.toggleClass('open'); And not this: clearMenus(); !isActive && $parent.toggleClass('open'); The no semi-colon crowd is ridiculous. There are no good arguments for omitting semicolons!

latortuga 15y ago

I have grown extremely weary at the level of discourse that this whole situation has provoked - the linked post is one ad hominem after another! What is this supposed to accomplish? Hopefully I can get the people I'm criticizing to change their ways by making them feel really bad about themselves? By telling them they aren't visionaries, they are semi-colons, they are arrogant, sloppy, lazy? It's destructive, self-indulgent, and completely unnecessary.

whateverer 15y ago
I upvoted you. This whole semicolon war is the most banal and self-aggrandizing conflict I've seen in a while, rife with as much vanity and childishness a the ``blogosphere'' allows, as evidenced by this post. Can we move on, please? At least everyone acknowledged that the editor war was an inside joke, I would gladly have an editor thread every week on HN over this.

ExpiredLink 15y ago

> The main issue with these parser-fetish arguments is that they assume that you write code for a parser – sometimes even a certain browser – and not for other developers. That's an excellent and important point beyond the petty incident. You write code solely for humans, not for the compiler.

n_time 15y ago

To me this argument boils down to style over maintainability. The arguments for the latter seem so clear in my mind that I don't really want to dignify the other side with a response.

LeafStorm 15y ago

I come from a Python background. However, thanks to work and school, I now program mostly in JavaScript, PHP, and Java (though I still use Python when I get a chance). Now, I could use underscore_names in Java and JavaScript, but I don't. Even though I personally prefer underscore_names to camelCaseNames, I also realize that those languages are designed with camelCaseNames in mind, that the community conventions are for camelCaseNames, and that it is better to write code that looks nice and idiomatic in that language than it is to write code that looks nice and idiomatic in Python. Not to mention that there are some cases where camelCaseNames are required - for example, when overriding inherited methods in Java - and if I used camelCase where required and underscore_names everywhere else, my code would be inconsistent, which to me is worse than using a style I don't like. So just because I could use underscore_names when I wanted to, there are a lot of reasons that I shouldn't. A lot of those points also apply to JavaScript: * JavaScript was designed with the use of semicolons in mind. Brandon Eich himself has said that ASI was only intended as an extra check for sloppy programmers. * Outside the Ruby on Rails crowd, all the JavaScript I have ever seen uses semicolons. Even within the Rails crowd, this "no semicolons" thing is fairly recent. * Since the majority of JavaScript syntax is intended to mimic Java syntax, which does require semicolons to separate statements, semicolons blend well with the language, and are therefore nice and idiomatic. * There are situations where you have to use semicolons due to ambiguity to write straightforward code - there are workarounds, like tricks involving !, but they confuse the intent of the code. One thing that I noticed is that most of the notable semicolon-haters - fat, mislav, and the GitHub guys - come from Ruby on Rails. Conveniently enough, Ruby does not require semicolons at the end of statements. I suspect this anti-semicolon fervor may come from a desire to use Ruby's conventions with JavaScript.

jrockway 15y ago
Incidentally, we use CamelCaseMethodNames in Python at Google, presumably to be consistent between languages. If you're one company that uses multiple languages, it may be beneficial to use the same style in each, even if that style is non-idiomatic.
- frio 15y ago

benatkin 15y ago

The author is picking and choosing who he wants in this argument of his. He has Douglas Crockford and Brendan Eich on the pro-trailing-semicolon side. On the other side he has @fat. If he wanted to be fair he could have included someone like @izs or Thomas Fuchs. But if he referenced their viewpoints on it, it would make it harder to pretend that all code that doesn't include trailing semicolons after every statement is brittle.

Isofarro 15y ago
"He has Douglas Crockford and Brendan Eich on the pro-trailing-semicolon side" Brendan Eich, the conceiver of the language. The best placed person in understanding why the JavaScript language does what it does, and what problem a feature was trying to solve. Douglas Crockford, the developer who took all of JavaScript and found within a clean elegant language. And then he pulled together what he considered the best bits of the language and used that subset as a starting point. http://anongallery.org/220/javascript-the-good-parts http://anongallery.org/220/javascript-the-good-parts @fat - no idea who he is, apart from being an employee of Twitter and works on Twitter Bootcamp, which is a framework for other people to use to build websites. @izs - I think you overreach by grouping him as anti-semi-colon. Isaac is a pragmatist, he uses what suits the group of people he works with. NPM is a standalone app, a non-expert JavaScript developer doesn't need to delve into npm for it's standard usecases. So he choses a syntax he believes suits the group of people working with him. And yet, he is now the lead developer of Node.js, and he's already on record saying he won't be spending time changing Node.js into his preferred comma prefixed approach - because the existing team is already used to post fixed commas. That's what I like about Isaac - he listens to a wide range of opinions, and uses what works best for the environment he's in. Thomas Fuchs - heard of him, he's done lots of stuff JavaScript and PHP wise. I'll give you that one. He gave us Scriptaculous, and some decent PHP resources (like PHPatterns, IIRC). He's active in Rails. The main reason the quality of JavaScript has increased dramatically in the last 6 or 7 years has been because of a coalescing towards a JavaScript best practice. This has mainly been led by Douglas Crockford and JavaScript developers at Yahoo. JavaScript is too flexible and too bastardised a language, leaving lots of weird and broken features. Plus, well written code isn't about being clever, it's about writing code that can be supported and maintained. Douglas has taken the best bits of JavaScript and found that to be quite an effective and useful language. With that subset he, along with the people who later became the YUI library developers wrote code in that subset. The reason for that subset is that the language is clearer, less ambiguous, and less likely to catch a developer out. Turns out using just a subset of JavaScript's syntactic capabilities improves the quality, reliability and maintainability of code. JS Lint was build to help developers bring their code into line with this subset of usage, and disallow perfectly valid but potentially flawed code. It favours code that is readable and quickly understandable by the non-expert developer. JS Lint is the starting point for this improved use of JavaScript. JS Min is built, as far as I understand, with the assumption that JSLint rules are in place, so yes, it works on a subset of the language. Actually the documentation http://www.crockford.com/javascript/jsmin.html http://www.crockford.com/javascript/jsmin.html is more specific: "It is suggested that JSLint be used before using JSMin." And I guess that's the real problem here. Not using JSLint before using JSMin. And then this argument boils down to @fat saying something along the lines of not wanting to be constrained to JSLint's subset of JavaScript. That's a call he can make, and the users of Twitter Bootcamp can then choose accordingly whether to use the toolkit (since if you are in a JSLint / JSMin using environment, it's probably best to stay away from Twitter Bootcamp.) Perhaps what would be worthwhile is a JSLint equivalent for whatever syntax and idioms the Rails-induced subset of JavaScript uses (not just a watered down version of JSLint that JSHint is, but something that encourages what they consider to be best practice rather than merely allow it), and a minified that respects those idioms. And something in plain English for those unfortunate developers who stumble into these idioms. What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?

stiff 15y ago

I think the real issue in the whole debate is that 95%+ of people programming do not understand how programming languages are implemented and haven't been exposed to basic theoretical stuff e. g. to the fact that languages can be ambiguous, that there are cases where it might be impossible to interpret a part of the code, that handling syntax errors is actually hard etc. This post is a good example, it completely misses the point, as the only reason semicolons are present in some languages is to make parsing possible. I think many people would not argue about this if they had a clue why programming languages syntax is the way it is.

Tichy 15y ago

Somebody should do a HN poll. I bet it was already done, but I am too lazy to search for it.

stcredzero 15y ago

tldr from the article: So, if your code needs syntactical changing when it gets extended, to me you’ve optimized prematurely. Code will always change and making sure our maintainers have a hard time breaking it is a very simple and good idea. In other words, a good programmer writes code for project maintainability, not to signal dominance by showing off knowledge of the parser. [+] (Corollary: One's cleverness is always a finite resource. I'd rather work with someone who devotes that resource to what's good for the project, not his own fame and ego.) [+] - Unfortunately, the way teaching CS sometimes works, students are rewarded for showing off clever and elite code every chance they get, to show the prof they're a "real" coder.

bitwize 15y ago

Every programmer should have had a professor who was really, inordinately fond of Ada, so much so that at least one assignment required coding in, or basic knowledge of, the language. Ada is strict as balls, but unlike its wannabe-successor, C++, its strictness is for the sake of clairty and the compiler usually actively helps you bring your code into compliance. (Rather than, say, complaining randomly because the syntax for template instantiations changed this week, or punishing you for pronouncing the word "const" with the improper intonation.) With a bit of exposure to Ada, programmers might understand better why languages are so finicky about syntax details, and that just because a language is lenient, doesn't mean you should take advantage of that leniency. And that, in cases like JavaScript with its bloody semicolons, perhaps leniency is a disadvantage.

rblatz 15y ago
I had a professor like that, he also was a signatory to the original ECMAscript standard. He also claims he came up with that name. Since they were spending too much time debating the name, he figured they'd call it that for now, and since it was such an awful name they would be sure to go back and change it.

buster 15y ago

Reminds me how learning python took all the fun out of those semicolon and curlybraces loving languages. Americans (with US keyboards) really shouldn't design a programming language nowadays.

lucian303 15y ago

This is ridiculous. Twitter's developers are lazy. You don't NEED a semicolon for the interpreter, you NEED a semicolon for the other readers/users of your code!!! That goes for all other code practices that enhance readability. If you disagree that human readability is less important than interpreter/compiler, you're a lazy moron. Period.

chaostheory 15y ago

This argument is pointless. At the end of the day, the current owner of Bootstrap can do whatever he wants. If the semi-colon issue is that important, people should just fork the project and add semi-colons.

agranig 15y ago

Writing great code means making it easily readable and understandable by other developers. If you want to show off your quirky syntax skills, for god's sake play perl golf or attend at obfuscated code contests.