An Open Letter to JavaScript Leaders Regarding Semicolons | Hacker News Reader

An Open Letter to JavaScript Leaders Regarding Semicolons

blog.izs.me

84 pointstswicegood77 comments

I think that issacs is missing the part where other people try to read his code. We put semicolons at the end of each statement, even though it's shorter to leave them out, because it's how JavaScript is written, and how others are comfortable reading it. We spell English correctly, even though it's full of meddlesome "ou"s and "gh"s, because that's the way English is spelled. In fact, issacs' proposed semicolon-less, comma-first style reminds me of Mark Twain's "Plan for the Improvement of English Spelling":

    For example, in Year 1 that useless letter c would be dropped to 
    be replased either by k or s, and likewise x would no longer be 
    part of the alphabet. The only kase in which c would be retained 
    would be the ch formation, which will be dealt with later.

    Year 2 might reform w spelling, so that which and one would take 
    the same konsonant, wile Year 3 might well abolish y replasing it 
    with i and Iear 4 might fiks the g/j anomali wonse and for all.

    Jenerally, then, the improvement would kontinue iear bai iear 
    with Iear 5 doing awai with useless double konsonants, and Iears 
    6-12 or so modifaiing vowlz and the rimeining voist and unvoist 
    konsonants.

    Bai Iear 15 or sou, it wud fainali bi posibl tu meik ius ov thi 
    ridandant letez c, y and x — bai now jast a memori in the maindz 
    ov ould doderez — tu riplais ch, sh, and th rispektivli.

    Fainali, xen, aafte sam 20 iers ov orxogrefkl riform, wi wud hev 
    a lojikl, kohirnt speling in ius xrewawt xe Ingliy-spiking werld.

Sorry, had to try:

    For example, in Year 1 that useless letter c would be dropped to 
    be replased either by k or s, and likewise x would no longer be 
    part of the alphabet. The only case in which c would be retained 
    would be the ch formation, which will be dealt with later.

    Year 2 might reform w spelling, so that which and one would take 
    the same consonant, while Year 3 might well abolish y replacing it 
    with i and Year 4 might fix the g/j anomaly wronse and for all.

    Generally, then, the improvement would continue year by year 
    with Year 5 doing away with useless double consonants, and Years 
    6-12 or so modifying vowels and the remaining voiced and unvoiced 
    consonants.

    By Year 15 or so, it would finally be possible to make ius of thi 
    redundant letters c, y and x — by now just a memory in the minds 
    of ould doderez — to replace ch, sh, and th respectively.

    Finally, then, after some 20 years of orxogrefcl reform, we would have 
    a logical, cohernt spelling in ius xrewawt the English-speaking world.

ould doderez = old dodders

orxogrefcl = orthographical

ius xrewawt = use throughout

Thank you! I tried googling the answer before pasting it all over HN but to no avail.

Oddly, I found that mostly readable, though there were a few implicit changes that he failed to spell out, so you need to infer those.

I have a friend who is dysgraphic. His writing is basically 100% phonetic. To read it, I find it easiest to read it out loud, and listen to myself talk. This reminds me of that.

Of all the satire I have ever read, that may very well be the best, because to this day I am still not sure of the exact proportion of joke vs. seriousness. And I've read my Twain, so it's not unfamiliarity with the author. That's the mark of a truly masterful satire.

npm is a hobby project designed to bring me joy. As a side-effect, a lot of node users find it helpful. That's great, and I'm proud, but honestly, if everyone stopped using it, I'd keep hacking on it.

A little boy may grow up to be the doctor who cures cancer. But that's not why you have children.

Yessir -- I'll vigorously defend your right to code in a style that floats your boat, but that's not what your blog post is: it's an evangelization of semicolon-free, paren-first style (hereafter known as SchlueterScript). You're asking the JS thought leaders to stop slandering your chosen syntax, and this comment thread contains a hundred reasons why most folks would rather not. I can dig the groovy art project also known as npm, and at the same time also rather not come across more SchlueterScript in the wild. A bit hypocritical, sure, but also heartfelt.

Read it again.

I spent significant chunk of the post explaining that a) I don't care how you code, and b) there are some good reasons to choose a different style than mine.

I'm asking JS thought leaders to stop encouraging falsehood. That's all. "Don't code like Isaac because it's ugly." Fine. I can dig that. Maybe you won't date me because you think my face is ugly. You wouldn't be the first one, and thankfully for my social life, it's not a universally held opinion.

But "don't code like Isaac because ASI is unreliable and no one understands it"? Patently false, and OMG PEOPLE ARE WRONG ON THE INTERNET.

This is so far beyond goofy. Don't we have jobs or something? Who posted this? Jeez. Get that guy something better to do.

For me the reason to always use semicolons is the same reason I always use ===. There are just too many rules to remember and I've got more important things to keep in my mind.

It's also good to have your JavaScript look like the JavaScript most other people write. I have practiced many different coding conventions in my life, and I don't really hate none of them, but the thing I do dislike is context-switching between different conventions in different projects. We already have tabs v/s spaces and several other possible differences. It would be nice to exclude the choice for semicolon placement from that list.

I do agree with the author in one point: you should understand how automatic semicolon insertion works. And then make up your mind about it. Don't just blindly follow anybodys advice.

Maybe an inappropriate question, but could you explain the significance of === to the unenlightened amongst us?

Comparing with === does not perform type coercion, while == does and the rules for type coercion in JavaScript are even more funky than for semicolon insertion.

The standard equality operators (== and !=) compare two operands without regard to their type. The strict equality operators (=== and !==) perform equality comparisons on operands of the same type. Use strict equality operators if the operands must be of a specific type as well as value or if the exact type of the operands is important. Otherwise, use the standard equality operators, which allow you to compare the identity of two operands even if they are not of the same type.

So: (1 == '1') is true;(1 === '1') is false.

https://developer.mozilla.org/en/JavaScript/Reference/Operat...

And, strangely, (NaN === NaN) is false. Gotta use isNaN(NaN).

That's the only part of Javascript's ==/=== dichotomy that I like. It maps directly to the way NULL works in SQL. NULL means "I don't know what this is," so two unknown things can't be tested for equality because you don't know what they are. NaN is a similar concept. You tried to make a number, it borked, how can you test one bork against another for equality?

I hadn't thought of it that way (comparing borks, not sql null); it does make some sense in that light (though then you should be able to compare the same NaN in two variables...).

Though that undefined === undefined works, and so does Infinity === Infinity doesn't make as much sense when thought of that way; infinities aren't all equal, and undefined isn't a single kind of value that it makes sense to compare as if it were. And to counteract the sql null viewpoint, (null === null) works.

Also:

  var x = parseInt("a");
  x === NaN // false
  alert(x); // "NaN"

doesn't make a whole lot of sense. isNaN() performs the exact same thing that === NaN implies. Especially as:

  {}.x // undefined
  {x:undefined}.x // undefined
  for(prop in {x:undefined}) alert(prop); // displays "x"
  {}.x === {x:undefined}.x // true

Meh. It's a weird language. Not intending to shoot you down; just spilling my brain into a textbox.

That's to match IEEE-754, x==x will return false if x is a NaN in just about every language I can think of.

An interesting property of this is that == isn't transitive

  '' == 0 // true
  0 == '0' // true
  '0' == '' // false

I think this is the most important point: if understanding when or when not to use semicolons requires a subtle understanding of the language grammar, then terminating every statement has a cognitive cost. This cost adds to coding friction.

I don't personally use JS, but I do use C/C++ and Python. I prefer Python's syntax because I find it clean. Most of my work is in semicolon-and-brace languages, so I'm clearly familiar with that style, too. But were I to code in JS, I'd always use semicolons, because that's easier than constantly asking myself, "Do I need a semicolon or not?"

As an analogy, I use my turn signal every time I make a turn in my car. Every time. Even if I'm in an empty parking lot. That way, I never have to decide, "Should I use my turn signal?" It's just automatic. It reduces the amount of thought I have to put into things that don't actually matter.

Here's what Crockford has to say on the subject:

"One of the mistakes in the language is semicolon insertion. This is a technique for making semicolons optional as statement terminators. It is reasonable for IDEs and shell programs to do semicolon insertion. It is not reasonable for the language definition to require compilers to do it. Use semicolons."

http://javascript.crockford.com/survey.html

I'm inclined to agree. You already have to deal with enough complexity while you're programming, why add more? It's easier to follow the rule 'always use semicolons' than to try to selectively use them.

The counter to that argument is "You already have to deal with enough visual noise while you're programming, why add more?". Semi-colon insertion rules aren't that complicated. To me, it's a matter of what style project participants are comfortable with.

Rules may not be complicated. Seeing where and how they should be applied in the sea of code, some you did not write—entirely different story.

I agree use semicolons. Or longer:

Because JavaScript allows semicolon insertion some syntax is parsed in a way which is surprising to those skilled with other curly brace languages. This can causes problems if you do or don't try to leave out semicolons.

The solution to avoiding unexpected behavior is to run JSLint. JSLint will insist that you use semicolons. So you will have to use semicolons.

Since my http://eloquentjavascript.net recommends always terminating statements with semicolons, I guess I'm being directly addressed by this.

The suggestion that 'I don't understand semicolon insertion' doesn't really hit the mark. I wrote a JavaScript implementation.

Yet still I recommend everyone to use explicit semicolons. Going over the proposed style on this page, it all sounds pretty good, and semicolon insertion is starting to look okay. Until you realize that he wants you to start every line that starts with [(+/-,.* with a semicolon. This is needed to prevent semicolon insertion from failing you.

I'm sure one can get used to such a style, but it is completely 'out there', radically disconnected from JavaScript's C parentage, and, though that's a question of taste, ugly and irregular. This solution is worse than the problem, I think.

"Until you realize that he wants you to start every line that starts with [(+/-,.* with a semicolon."

Good point, that isn't immediately clear.

To help me understand, the article listed an example where a line started with a [, what are situations where a line is likely to start with (+/-,.* ?

The immediate-function pattern starts with an open paren.

(function () {

}());

So you do this to nest temporary variables in another lexical scope inside of another outer function? (as vars have function scope rather than block scope)

I'm not sure I would use this much, though now that you have pointed it out, I had better well be able to read it when somebody else does it to me. Thanks, I think.

Most javascript modules are defined inside a similar pattern, I'm surprised you haven't seen it yet.

http://www.adequatelygood.com/2010/3/JavaScript-Module-Patte...

https://github.com/jquery/jquery/blob/master/src/ajax.js

Odd. I've usually just returned or assigned the function def without the outer parens. For some reason, the outer parens syntax looked like it was defining an anonymous function, and also calling it immediately, which is of course not what that turns out to do.

It's an interesting language, but I'm still at the dabbling stage. I'd like to think I'm past the voodoo stage (onfoo="whack()" attributes that call in-page functions with global variables), but maybe not.

I don't mind you telling people to end lines with semicolons.

I'd mind it if you told people that omitting semicolons causes cancer. (Or bugs.)

-- EDIT:

I just looked up your book to the point where you make this recommendation. You don't threaten any catastrophes, which is good. I disagree with the "complex and weird" conclusion, but it's certainly a valid decision to leave them out of the book if you'd rather not go into it.

My opinion of you: Not Evil. <3

Finally, somebody else who hates the largely gratuitous semicolons.

Example: http://roboprogs.com/devel/2010.06.html

It's a shame they didn't just make it fully line oriented (like BASIC, xBASE, shell-script, Python, Ruby, ...), with the customary backslash or ampersand to indicate an incomplete line. (but they didn't) I guess then Netscape would have had to call it FooScript (or something silly like echhh-muh-script).

The worst thing I hate about the "add semicolons!" religion is that it teaches people not to spot statements that are going to be terminated by a newline. So then, I have to see all the extra noise on each line :-(

Don't people test the crap they write?!?

We programmers have a tendency to focus our arguments about code almost entirely from the perspective of code creation rather than maintenance, and I think that's in part what this article does.

An experienced coder who knows how Javascript works is unlikely to create problematic code even without semicolons, but it's fairly easy to imagine how errors could be introduced as a large, complex program is maintained by multiple developers, some of them potentially less experienced than the author. Like conditional braces in C, Javascript's semicolons are an optional syntax that can be used to make code more foolproof, and therefore more maintainable - though perhaps at the expense of some programmers' aesthetic preferences.

Really, though, I find most arguments about syntax aesthetics annoying, especially when people get their passions so inflamed over presentation rather than meaning that they have to risk "insulting" people. The stakes are so small. And if what you believe is so important, wouldn't it be better to convince people rather than intentionally alienate them?

People usually think there's a 1 to 1 correlation between "I like this" and "this is objectively good" and then spend a lot of time trying to logically justify their tastes. But taste doesn't really work that way - otherwise how else can you explain the popularity of Britney Spears?

I have my own tastes about how to write code in the languages I use, but I recognize that those preferences are generally just that - matters of taste - and tend not to try forcing them on others.

I agree, but I would like to quote the author : "This isn’t an article where I try to convince you to write your code like I write mine." He does not really try to force his style. I respect his approach, because even if the article seems to be about aesthetic preferences, I think that he is concerned by the lack of curiosity and education that may be shown by some programmers. I think what the author really says is : RTFM. None of the comments here focus on the conclusion of the article, which is the most important part:

"Cozy up with some hot chocolate and the ECMAScript spec some Saturday afternoon. Practice a little. Play around with some test programs. It’s a good time. Or don’t do that, if you don’t feel like it. It’s your life. You almost certainly have better things to do with it. Just please stop making authoritative claims like “terminate all lines with semicolons to be safe.” It’s not any safer, or more reliable."

Some programmers like to know everything about a language they are using, knowing all the edge cases, keywords no-one else uses, the exact execution order of tokens and weird quirks. They are masters of complete understanding, and very occasionally this mastery allows them to come up with a revolution in the way things are done. Let's call these the Scholars.

A lot of others don't though, the joy of programming for them is not mastery of the grammar but writing the story. They would rather use a combination of run it and see and diving into the documentation only when totally necessary. Do not mistake this for an amateur who is cargo culting their code, these programmers know exactly what their code does, they just learn the bits they need as they need them. Let's call these the Mavericks.

I struggled to find neutral words for both schools of thought, don't read too much into the names I picked.

Both types can be excellent hackers. And of course we have a spectrum in between Scholars and Mavericks.

I am a Maverick. I find the Scholars, with their memorization of all the rules, to be both awe inspiring and entirely tiresome at the same time. I don't enjoy sitting down with a cocoa and a spec because I'd prefer to be programming. There is a vast swathe of every spec and every library that is entirely useless for the task I have at hand, quite often for any task I would ever do. I see anything which forces me to learn that useless knowledge as a waste of time.

Use semi-colons for every statement is a simple and easily remembered rule, one which takes no effort compared to reading a spec that delivers me little or even no benefit. I will also tend to forget these rules because my mind just doesn't see it as particularly useful information, I don't use it enough. I don't have any motivation to force that knowledge in my brain through learning practices because to a Maverick, it's boring.

There is no lack of curiosity or education in the latter type of programmer. I read this type of article which Scholars so often write with exasperation. Mavericks just don't care about learning the intricacies of language grammar compared to doing something else in programming. That something else is just as intellectually demanding.

Please remember that the next time you come across a Maverick, we're just of different schools, not of different ability.

I appreciate your reply. I am not sure if I really am on the Scholars side of the spectrum myself, but I surely love to know how to use my tools appropriately (Googling instead of memorizing everything is efficient). There was an article recently on HN (http://news.ycombinator.com/item?id=1906070) related to "bad" habits in Perl (What about using the safer, clearer three-parameter form of open?) : as you and other expressed it more clearly than I did, this is the Cargo Cult side of programming that bothers me. Also, I was disappointed that most of the comments seemed to fight over stylistic considerations whereas the point of the author was "Just please stop making authoritative claims", e.g. uninformed claims; but don't get me wrong, I clearly noticed that people here actually know quite well their subject, even when they choose the always-use-semi-colon side of this war.

If you are a Maverick, then that's fine. Write code however you like. Seriously, I care less than anyone.

Just stop talking trash about how I do things. If the story is more interesting than the grammar, then shut up about grammar and go back to writing stories.

My problem is with telling people that there is a problem when there is no problem, and at the same time calling yourself a scholar.

If you don’t understand how statements in JavaScript are terminated, then you just don’t know JavaScript very well, and shouldn’t write JavaScript programs professionally without supervision

You obviously do care to such an extent that you're saying that we shouldn't even be programming without you looking over our shoulder.

I have a problem with the way the author puts forward his position: "I am sorry that, instead of educating you, the leaders in this language community have given you lies and fear. That was shameful."

As folks have said here, there is a valid alternative position. He's arguing as if there's no valid alternative ... which is problematic.

The author doesn’t seem to work in a team where the code is going to be touched by multiple people, all with varying levels of competence. It’s easy to explain to your colleagues that JS should have semi-colons added or weirdness can happen. It’s less easy to say ”Here’s the ECMAScript spec, go read it“ when they’ve got ruby and HTML and CSS and SQL to write and simply don’t have the time to thoroughly master each and every part of the stack.

The point is that always adding semicolons does not solve the weirdness problem. Consider:

    return
         17

This returns undefined, which is counter-intuitive if you come from other c-style syntax languages. But if you say "always terminate statements with a semicolons, otherwise weirdness happens", the intuitive fix is:

    return
        17;

Which still doesn't solve the problem. You have to remember an additional rule: "Don't insert line breaks in the middle of a statement, if the line break could be interpreted as a statement terminator." Or to put it another way: If you are in doubt, don't use a line break.

The problem isn't really if statements should be terminated with a semicolon or not. The problem is to decide when it is safe to insert a line break when it is not intended to terminate the statement.

Whoever linebreaks return statements like that deserves what's coming to them.

But I get what you're saying. Simple, consistent rules are better for teamwork.

I do that sometimes (obviously not in JavaScript), to split up long lines in situations such as this:

  bool is_foo_possible() {
    return
      test_first_condition() &&
      test_second_contition() &&
      test_third_condition()
  }

I don't think that's very horrible.

I would tend to write that:

  bool is_foo_possible() {
    return test_first_condition()
      && test_second_contition()
      && test_third_condition()
  }

I prefer to put my infix operators at the beginning of continuation lines, because that makes it immediately clear from a glance that it's a continuation line.

I do this as well.

For a while, I tried to stick to the rule that "return\n" was not allowed. When I meant to return undefined, I'd write "return undefined".

In the end, I abandoned that rule, because too many of my functions return undefined. But it's kind of a nice thing. When I do get around to building that linter, I might make `return\s*\n` verboten.

You could just write "return;", that would make it obvious that no value is returned.

OH. Good point.

He used to work at Yahoo. That's where I met him and while I never worked on a team with him, he seemed like a nice guy. Definitely smart, though his blog/writing style may come across as arrogant to some. I would have loved to end up on a team with him as I'm sure I could have learned a lot from him.

Thanks :)

While there may be nothing technically wrong with Isaac's style, and it may in fact be slightly "better" in some way, it's clearly not how the language was intended to be written or how the vast majority of people write it.

I would be ok with leaving the semicolons off, if you didn't have to do ridiculous things like prepend some lines with semicolons instead. It's easier for everyone just to put the damn semicolons in.

I couldn't care less what your pants policy is in your own home, as long as I never come over. But when you invite me over (i.e. open source a project) and you have a ridiculous pants policy don't expect me to come back.

I would be ok with leaving the semicolons off, if you didn't have to do ridiculous things like prepend some lines with semicolons instead. It's easier for everyone just to put the damn semicolons in.

It'd be nice if I had a linter to catch things like this. But really, it's not so hard to spot. I was bitten by missing semis often enough to start prepending [ and ( already, before I started just leaving them out entirely.

No one's going to cry if you don't contribute to npm. When I contribute to your project, I'll follow whatever style you like, and if I find it to onerous, I'll move on. Life is tradeoffs.

I do not like inconsistency. I never leave out curly braces. I never omit semi-colons. There is no reason to do so.

I dislike working on code written by people who feel the need to omit these symbols. I would prefer if JavaScript would, like PHP or C, require semicolons at the end of every statement.

Be very, very careful when you're using PHP as an example of the proper way to do something, because you're probably at least partially wrong. Semicolons are optional when followed by a closing tag (and likewise, closing tags are optional when the last statement ends with a semicolon -- in this case, whitespace at the end of the file is valid, as well)

Yes. There is one situation in which you may omit a semicolon in PHP.

This does not create a situation like the semicolon insertion in JavaScript, however, and I don't perceive as an ambiguity or inconsistency issue.

Are you saying this detail about PHP causes problems of some sort? I can't think of any. If JavaScript were to work like that, and only let you omit a semicolon before a closing script tag, that would be absolutely fine with me.

And so once again, Alan Perlis' famous quip is proved right: syntactic sugar causes cancer of the semicolon.

Seriously -- look at the complexity of these rules, and then tell me that Lisp's parentheses are worse.

Javascript isn't exactly the typical case of semi-colon usage here.

JSLINT will catch basically all of these problems for you automatically, with it you don't have to worry about improperly parsed code, semi-colon insertion, ==, for in, the stupid constructors like new Function and new Object, implied globals, or most of the crap in the language.

There are still some deep problems with JavaScript that no tool, not even JSLINT can fix, like the fact that the language uses + for both concatenation and addition, there is no namespaces, there is no way to create immutable objects, etc.

I recommend you use a good IDE (like Eclipse) and hook it up with JSLINT so that you can ensure that you don't ever accidentally create global variables or create statements that the parser doesn't understand.

http://www.rockstarapps.com/joomla-1.5.8/products/jslint-ecl...

This blog post reminds me of individuals who will only drink high quality naturally purified twice-filtered water from the mountains of Switzerland.

Which comes from Lake Michigan?

How so? I missed the part where I wrote about swiss water.

Mr. Chess, I both admire and fear the potency of your absurdism. I would compliment you further, but I am too afraid.

I honestly never thought that much about the use of semicolons vs not.

I'm not a hardcore JS programmer, I know enough to get paid for it, and I'm the best JS programmer of my current employer. But I'm far from a jedi master.

Isn't this just a matter of personal preference? A semi-colon is interchangable with \n as long as you use it following the same rules. Which I do because I treat it as a visual marker for the end of a statement.

The counter argument is why use it if the system already recognizes the \n in place there, for which I say to make it easier for other JS programmers to recognize and parse since the \n is used in other places where it isn't the end of a line.

I guess I don't really see this as a compelling argument being made here, or I've misunderstood what is being argued.

Most of the controversy stems from the fact that Doug Crockford, widely regarded as the javascript expert, has been aggressively saying "Use semicolons at the end of every statement or you will be miserable" for years, particularly in his influential book "Javascript - the Good Parts." You can see a presentation where he reiterates this point, among others, here: http://www.youtube.com/watch?v=hQVTIJBZook

This blogger has a pretty compelling argument against this view.

Actually, that's not what Crockford is saying. From the same link: "Figure out where the semicolons go. Put 'em in the right place. You'll be very much better off." That is a quote from 13:02 into the video. There is a trancript on the video, so you can read it too.

I won't claim Doug has never said something like that, but I doubt it. I watched many of his videos that can be found and he is always evangelizing learning the language, instead of blindly cargo culting.

You are totally right, I was paraphrasing somewhat flippantly, and I should have been more clear about this.

Doug is definitely high up on the list of my most respected programmers, everyone should definitely take notice of what he says. Any person who is putting out that much good information will eventually lay themselves open to some criticism, its the inevitable consequence of doing so much work.

Yes, I agree... what Crockford says makes sense to me. Know where they go, and use them consistently.

This blog post doesn't make so much sense. It seems to say that you should be aware of the rules at all times and strive to use as few semicolons as possible (even going so far as to put them in front of statements). Yes, it would work, but I don't really see this as more readable.

My recommendation to use minimal semicolons is a very weak suggestion. I took great care to make that clear, and to point out a few cases where it makes perfect sense to use more semicolons than strictly necessary.

My recommendation against lying is much more forceful.

Use semicolons, always. Then you don't need to learn all the rules and caveats and ambiguity.

Actually, if you consider the return example in the blog, you do need to learn some caveats and rules. That's the point.

No because you still have to remember that rule whether you use semicolons everywhere or not.

Anyone who would write return\n deserves all they get.

It's a fun example, but it would never happen in real life.

    function getCount()
    {
        return 
        {
            'count': 1
        };
    }

Not what I'd do, but a common style nonetheless.

It's also completely valid JavaScript that does something very different than what it appears to.

    function getCount () {
      return undefined
      { // open code block
        'count': /*labelled line*/  1  //numeric expression
      } // close code block
    } // close function

LINE BREAKS CONSIDERED HARMFUL.

Which is why I'd say if you're writing javascript, use { brackets properly, and ; properly.

I agree, it's a common style, but a horrible one IMHO.

Just because the rule exists doesn't mean it's the right thing to do.

Adding oddities to a language that could be small and simple creates these ongoing controversies. What are PHP developers _still_ talking about? SQL injection. What are Rails developers _still_ talking about? How to use REST properly. What are JavaScript developers _still_ talking about? Semicolon's or not.

This all points to poor design decisions in my mind. And we're at a loss to change the language unless we do something like CoffeeScript.

I think the reasons a lot of people use semicolons is that it's just easier. Also if you come from a language that enforces them, it's natural just to use them. That's why I use them anyway.

Hopelessly pedantic … use them (or don't), but either way don't waste too much time on this subject. Focus on things that matter more.

I completely agree. I really don't care how anyone writes their code. I care about self-described experts giving false information about the language to newcomers.

If there is pedantry, it is about the importance of either telling the truth or shutting up.

Reply on news.ycombinator.com