
Of parser-fetishists and semi-colons - Isofarro
http://christianheilmann.com/2012/04/16/of-parser-fetishists-and-semi-colons/
======
LeafStorm
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.

~~~
wahnfrieden
As a counterpoint, we decided to with underscored_names for our JS since we
work with a lot of serialized Python data structures via JSON and using the
same naming convention on server as client means our JS doesn't have a mix of
camelCase and under_scores for things received via JSON and things defined in
the JS. We're not writing reusable libraries for other projects to use, and we
don't use a heavy amount of 3rd party code, so it's no big deal.

~~~
quanticle
"using the same naming convention on server as client means our JS doesn't
have a mix of camelCase and under_scores for things received via JSON"

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.

~~~
wahnfrieden
Hm, how is that generally valuable to know? Maybe in certain use cases but for
us that would just be noise.

------
ajross
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.

~~~
tlogan
I think you missed the point.

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.

~~~
radicalbyte
Okay, I'm going to bite.

&& 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?

~~~
bzbarsky
In JavaScript, && does not evaluate to a boolean. It evaluates to the thing on
the left if that thing is false (in which case the right hand side is not
evaluated at all), otherwise to the thing on the right. So in said JavaScript
console,

    
    
      "asdas" && "da"
    

evaluates to "da" and

    
    
      "" && "da"
    

evaluates to "".

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.

~~~
nemetroid
Nitpick: you mean `if (!a) {r = a} else {r = b}` (or switched blocks).

~~~
bzbarsky
Er, yes. Of course I do. ;)

------
h2s
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
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
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
That's correct. You could use:

    
    
      !isActive && ($parent.toggleClass('open'), do_something_else())
    

but I don't think anyone would advise it.

~~~
chris_wot
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!

~~~
blasdel
there are even fewer good arguments for changing the semantics of the fucking
_logical negation operator_ 17 years down the line in a dynamic language with
billions of end users and no discrete versioning

~~~
chris_wot
About as logical as using the _logical negation operator_ for a purpose other
than logical negation. :-)

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...

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

~~~
dclowd9901
Because all you see it as is an argument about syntax. It's actually an
argument between the old guard and the up-and-coming hotshots.

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.

~~~
jpk
That's a pretty dramatized way of framing it, don't you think? I think the
take-away is as simple as this: JavaScript is a dumpster-fire, and we should
probably fix it so we can avoid more of this noise. Framing it as a soap opera
conflict instead of a teachable moment makes it more productivity-draining
than it already is.

~~~
dclowd9901
I'm only explaining what makes sense. I know, personally, I'm not going to
change how I'm writing my code because of what two influential Javascript
developers bitched about on a Github ticket, and I'm pretty sure I'm not alone
in that sentiment.

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.

------
raverbashing
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
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?

~~~
jeltz
Another advantage of the minifiers with a correct understanding of JavaScript
is that they can do way more advanced minifications like shortening variable
names.

------
LoonyPandora

        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#issuecommen...](https://github.com/twitter/bootstrap/issues/3057#issuecomment-5140916)

~~~
lucisferre
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
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.

------
ehutch79
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
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.

------
bmj1
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.

------
latortuga
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
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
> 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.

------
stiff
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.

------
mikeryan
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
Bootstrap and JSMin have both since fixed their code.

<http://news.ycombinator.com/item?id=3845267>

------
benatkin
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
"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>

@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?

~~~
benatkin
> @izs - I think you overreach by grouping him as anti-semi-colon [sic].

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>

~~~
Isofarro
"> 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.

------
VeejayRampay
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.

------
n_time
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.

------
bitwize
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
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.

------
Ramone
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
Surely the language is precisely what the spec says it is?

"The parser is the spec" is a nasty design smell, IMO.

~~~
ktizo
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
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.

------
mike_esspe
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
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.

------
stcredzero
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.

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

------
agranig
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.

------
chaostheory
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.

------
buster
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.

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

~~~
bmm6o
It's actually quite easy to develop software while being only vaguely aware of
and emotionally uninvested in these sorts of kerfuffles.

~~~
georgieporgie
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
As a reformed "alpha nerd boss", I suspect most people grow out of it.

------
lucian303
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.

