Of parser-fetishists and semi-colons
christianheilmann.com
christianheilmann.com
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.
If you're in a position where you can define that idiom, then by all means do so. But stay consistent so that when others join a project, or you leave a project, the intent of your codebase is well understood without needing to wade through pages of documentation.
So, IMO, while semicolons are important, they're relatively trivial and an easy "bug" to fix. If I'm looking for an authority, I typically check out the Google Style Guides.
A similar, though more pressing issue that I've faced recently is the proper parenthization of conditions for if. It's generally nice when you don't have to spend a minute or two remembering/looking up the nuances of C++ operator precedence. Know all of the intricacies and tricks for a language doesn't mean every member of your team knows them that well either.
However, fat and co. aren't avoiding semicolons because there are technical constraints that require them to avoid them. They just seem to not like semicolons.
Couldn't that almost be viewed as a feature, rather than a bug? I mean, this way you can instantly tell if a particular variable was received from the server via JSON or was defined in the client code itself. I would consider a naming distinction like to be a benefit, rather than a harm.
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.
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.
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.
When it comes to this particular case, I've heard a few different arguments for why the syntax they use is poor, including the following:
1. The syntax relies on parsing behavior that is expected to change in the future.
2. The syntax they use does not work in one of the major minifiers used throughout the community (the crux of the whole issue to begin with, but certainly a drawback in and of itself)
I have yet to hear any benefit to NOT including a semi-colon to resolve this issue beyond aesthetics, and aesthetics alone is just not a rationalization that I can get behind.
Isn't that exactly what's happening here? A bunch of people piling on skipped semicolons and infix if's because they think they're "sloppy"? Refusing to support ASI (which is, in fact, precisely specified) in their transformation tools because it's "broken"? Why are some people's aesthetics more important than others?
Again: you use the language you have. You will never get the community on board your private yacht of your "sane subset" Javascript. It's been tried for decades. It doesn't work.
That's basically the take-away I got from yesterday's semicolon drama. You can appreciate that JS allows you to omit semicolons or you can bash those who choose the ambiguous over the explicit. But if you're the lead on a hugely successful project you should pick the syntax that will make it work everywhere. It's especially odd for a web developer to choose aesthetics over pragmatics when it comes to things like this.
This is not really about whether semicolons are required or not.
The point is that in order to ensure maintainability of code you should try to use language (and framework) in a way which ensures better maintainability, supportability, and portability of your code.
Look, the statement like "a && b" is 100% valid in many languages but in order to increase maintainability, supportability, and portability of your code it should be written like "if (a) { b; }".
The easiest way to understand the point of this rule is to get a job maintaing some old crappy code-base :) - I learned that way.
Learn to read and maintain the language you have, because you can't win this.
&& is logical AND, and it operates on boolean expressions (or types).
So "a && b" evaluates to true if both a and b are true.
How can that be replaced by "if(a){b;}"?
Is it "r = a && b" being replaced by "if(a){r=b}"?
Using Chrome's javascript console:
> a = "asdas"; b="da"; a == b; false
> a = "asdas"; b="da"; if(a) { b }; "da"
Could you (or some other javascript expert) explain it to me?
So the second operand can be a function / method, with any (or no) return type.
> function bob () { alert("bob") }; true && bob();
Alerts "bob".
Nice trick, though not something I'd personally ever us as it's not concise and isn't portable to C# (and I assume Java/C++).
Plus using the IF statement is a better showing of intent.. and I don't really like relying on job security through obscurity..
Don't pass judgement on syntax you literally just learned, basically. Don't assume the world you know is the only one worth knowing. Good hackers know their tools.
It is a neat trick though, and proof that I need to spend a little more time hacking in javascript to improve my knowledge :-)
"asdas" && "da"
"" && "da"
So in an assignment context |r = a && b| would need to be replaced by: if (a) { r = a } else { r = b }, which may or may not be more confusing than the original statement with &&. But in a statement context, where the result of && is not being assigned to anything at all, "a && b" is exactly the same as "if (a) b;" except harder to understand.
if (a) { b; }
That's taking the quote out of context, which is saying a lot because it's a oft-quoted example of Donald Rumsfeld's tap-dancing. I doubt Mr. Rumsfeld was advocating driving around in Humvees as if they had armor. I'm sure he would laud the attempts of soldiers to improvise and mitigate the risks inherent in their equipment as much as possible.
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.
Over a decade of experience consulting in that world has shown me that adherence to code conventions has tremendous benefits. In shops where there was strict adherence to code conventions, I could be 10X or 100X more productive when refactoring using automated tools.
If you want to use Javascript, you have to take the whole language -- warts and all.
You need to justify this. This strikes me as a silly and counterproductive notion. Even in a tiny language like Smalltalk, you don't want to use, "the whole language -- warts and all," every chance you get. Hacky tricks have a cost. Just because you can implement an entire parsing system using doesNotUnderstand handlers, doesn't mean you really want to. (And yes, I've seen this happen in real life -- you really Do Not Want!)
!isActive && $parent.toggleClass('open')
if (!isActive) {
$parent.toggleClass('open');
}
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.
!isActive && ($parent.toggleClass('open') || do_something_else())
This actually reminds me of some cool hacks with structure pointers and functions in the Linux kernel.
!isActive && ($parent.toggleClass('open'), do_something_else())
clearMenus()
!isActive && $parent.toggleClass('open')
clearMenus()!isActive && $parent.toggleClass('open');
clearMenus();
!isActive && $parent.toggleClass('open');
So, how would you implement this dereferencing feature? given that this wouldn't be an issue if you added a semicolon, not sure why you are so hetup there...
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.
Edit: the point is that sometimes arguments seem stupid because we don't always say (or even know) what we really care about.
But, to suggest that simply removing semicolons constitutes some grand gesture towards readability, simplicity, or something as grandiose as a "minimalist aesthetic," is...beyond absurd.
It is Bike Shedding Qua Bike Shedding.
"We have met the enemy, and he is us."
hahaha - I feel the best use of this thread is that we agree to spawn a series of blog posts debating the most boring debates to hit HN ever. Including sock-puppets to randomly drop surprise left turns like "no you are all wrong, here is why the ocaml vs haskell debate bores me" and "no, the real boredom is the long comment threads in the ongoing 'anarco-socialist' vs 'enlightened-libertarian' viewpoint wars"
:)
I started programming and hacking because i wanted to make something cool and interesting which others would appreciate, not to bicker about something as silly as semicolons. If i wanted to do that, i'd work in retail. When an argument over something so trivial gets to this level, i cannot help but be bored by it.
It boggles the mind that so many otherwise intelligent people have decided to take the time to form an opinion about semicolons.
"In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake."
It was interesting for me to learn about the possibility of using that kind of '!' notation in JS, even if it's impenetrable to most other developers. Maybe I'll be able to parse some other hipster's code thanks to this.
One side chooses a style that they find aesthetically-pleasing even if it causes issues for some small subset of potential users.
The other side is flabbergasted that someone would be so reckless and argues for the sensible, safe option, which requires simply terminating your lines of code with an extra character, making those few issues for a small subset of potential users vanish instantly.
http://www.wordsbyf.at/2011/10/31/i-dont-write-javascript/
He says he doesn't use semicolons, except that it caused issues for those who concatenation scripts so he adds a semicolon to the end of the js file. But, lo! This causes issues for those who use the following pattern:
(function() {
// Le code
})()
!function() {
// Le code
}()
(function() {
// Le code
})()
!function() {
// Le code
}()
Nobody really cares one way or another, and while it would take Twitter more time to append changes to their code than it would Crockford, my guess is the trouble for either would be negligible.
That said, this is very obviously a pride war between those who stick to convention and those who undermine it. The question isn't "should we use semicolons", it's "who is going to start dictating the direction Javascript goes from here on out?"
Clearly, both of these individuals want that spot, but if there's anything I've learned in my short time of coding, convention always wins out.
I'm merely explaining why it's drawing so much attention, and what nerves this debate seems to be touching, because as a technical debate it is insanely boring. But that's clearly why it's not strictly a technical debate.
I'd frame it as "a pride war between people wanting a sane codebase not based on fragile parser edge cases --include two that know the language inside out--, and the developer of some minor js code that thinks he's too clever for all that".
That's no "undermining convention", that's juvenile bs. I know who I'd rather have on my team.
The problem is that jsmin is a naive pile of textual replacements (though not quite as abysmal as John Gruber's markdown.pl) instead of being a javascript implementation — something that actually parses javascript into an AST and compiles it to minified javascript.
He left out cases for several unary operators so it broke perfectly valid code. After bitching at them he came to his senses and fixed it: https://github.com/douglascrockford/JSMin/commit/5ca277ea452...
Unless for some reason you need your minifier to be trivial enough to be portable with no dependencies, you should really be using something along the lines of google's Closure Compiler, which produces far better output and even has stuff like tests!
Yes, it worked according to how the parser was designed.
But it depended on a frowned-upon parser feature (AST), that can lead to ambiguous or faulty results in similar cases, and for no good reason. When the creator of the language and its biggest guru disagree with your code style, well, there's no much room for an argument, even if all known implementations work fine with your code.
He also did an idiotic ?: operator abuse instead of a clear "if" in the same exact line. He probably likes silly "succinct code" tricks, which even C people wouldn't touch with a large pole...
Maybe the next time a language designer contemplates including such a feature as ASI, he/she will remember this furore and reconsider.
But that's what I always do: scan for the interesting bits or move on.
"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.
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?
How much time would be saved by widespread use of "The Good Parts" of Javascript? This is likely to be much larger than the time you propose.
How much mental effort is needed to support half a dozen different minifiers that all support a different subset of the language
Who says you have to? If the community as a whole started omitting the hairy parts of the language, they would tend to converge on the same core. A superset of the 5 or 6 most popular subsets is still going to be a lot cleaner than the whole hairball. In practice, this is about the coverage that just about any language gets from tools like compilers and code transformers -- after all, the serious tools pretty much all have bugs. A superset of the 5 or 6 most popular language subsets is all anyone gets in practice.
Now, this could be easily solved – by adding the friggin semicolon.
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#issuecommen...
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.
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.
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?
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.
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.
That's an excellent and important point beyond the petty incident. You write code solely for humans, not for the compiler.
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.
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
@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 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?
Those are your words, not mine. The "other side", as I put it, isn't necessarily anti-semicolon. To be on the other side of this particular argument, they merely have to disagree with the assertion that a semicolon at the end of the statement is a must, and not a style choice. And izs did choose that style for npm.
> 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.
There's Zepto.js too, and he was a longtime core member on the Prototype JavaScript framework. He's influential.
> 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.
I strongly disagree. The driving force was the increase in importance of the JavaScript language. He was part of that trend. He helped speed it up, but it would have happened regardless.
> JS Lint is the starting point for this improved use of JavaScript.
JS Lint is a starting point. There are other valid starting points.
> And I guess that's the real problem here. Not using JSLint before using JSMin.
But @fat isn't using jsmin. And there are great alternatives, so this is a valid choice!
> What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?
It would look like this: http://pragprog.com/book/tbcoffee/coffeescript
Err, that's CoffeeScript, not JavaScript. CoffeeScript gets cross-compiled into JavaScript. It isn't JavaScript in itself.
As for crockford leading the way to sanity, the biggest problem I have with him is that instead of warning and educating he flat out forbids, and then heckles people who disagree. "with" is considered a "bad part", but it is used by literally every js template framework. He recommends closure based object construction, but in a big app that is a memory nightmare. And then there is stuff that basically treats js devs as mindless idiots. Like the "new" operator is discouraged, just in case someone forgets to use it when they want to instantiate something or the function keyword is discouraged, because it hoists.
All of those are opinions, and some are demonstrably terrible. But for some reason The Good Parts is still held up as gospel, while the community just chooses to ignore the parts of the book it doesn't like.
As for minifiers, JSMin is pretty obsolete at this point. If you are using it, as an incredibly easy win you can decrease your page load times by using uglify js, google closure compiler, or yui compressor. All of these support asi fully, but that is probably the least important reason to use them.
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.
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.
"The parser is the spec" is a nasty design smell, IMO.
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.
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.
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
At least for me, mental switch between semicolon and no semicolon is hard for some reason, if it happens a lot during the day :)
It's kinda presumptuous to assume that people who disagree with you don't "understand the logic behind" your position.
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.
[1] - two or more is even worse: they're like male gerbils or betta fish, in that they fight all the time.
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.