Live data from Hacker News

Brendan Eich: The infernal semicolon

brendaneich.com

31–40 of 143 posts

Re: Brendan Eich: The infernal semicolon

#31
post #7

Earlier quoted context omitted.

That doesn't sound right to me. Making s language's syntax more liberal is not a sane way to correct errors. If anything, JavaScript's ASI is an error creation mechanism.

Yes, he's acknowledged many times (including in this post) that it was a mistake. That was the intention, but it wasn't successful. It should have gone all in (no semicolons at all) or not have existed.

I think it was a reasonable decision at the time. The idea was that JavaScript was not going to be some language people wrote hundreds of thousands of lines of code in, and that the target audience would become frustrated if the language didn't "help" them. For example, if JavaScript truly were to always require semicolons at the end of lines then that means this would be a syntax error:

...

> Error, missing semicolon after ")" on line 1

That could get pretty annoying pretty fast, and simple little event handlers like these were probably the main use of JavaScript for the first x years. It also matched the existing philosophy of HTML which was to really go out of its way to make sense of whatever was in the file.

Now of course, the constraints are different: people want to use JavaScript for huge codebases and serious projects, so it makes sense that these decisions are no longer appropriate.

Re: Brendan Eich: The infernal semicolon

#32
post #7

Earlier quoted context omitted.

That doesn't sound right to me. Making s language's syntax more liberal is not a sane way to correct errors. If anything, JavaScript's ASI is an error creation mechanism.

I believe he refers to error correction as in it corrects errors in the code -- i.e. the code itself should have semicolons and is fixed through ASI.

Right. To avoid confusion, I updated the post so the sentence reads

"ASI is (formally speaking) a syntactic error correction procedure."

Re: Brendan Eich: The infernal semicolon

#33
Heh, I was waiting for this post. Coming in the next 24 hours:

- "Why I use minimal semi-colons in Javascript"

- "ASI is broken but I like it"

Honestly I'm shocked at the defense of this practice (of ASI "abusage"). It speaks loudly to Jacob's (fat@githib) ranking of ego-stroking and showboating over creating readable code, particularly for a library "Designed for everyone, everywhere" [1].

I'm confounded that such an attitude can survive in a large engineering organization like Twitter. Google's style guide [2] specifically prohibits this ("Always use semicolons.") and yes, this is the same standard we use internally for writing Javascript.

Just because you can doesn't mean you should. FFS, just get over yourselves and your hipster bullshit and use semi-colons.

[1]: http://twitter.github.com/bootstrap/

[2]: http://google-styleguide.googlecode.com/svn/trunk/javascript...

Re: Brendan Eich: The infernal semicolon

#34

Moar downvotes! Can we reconsider using this thing as the assembler for the web? Can we come up with a sane, cross-platform bytecode standard?

Lars Bak, who leads chrome's v8 team and was tech lead for java's hotspot vm, argues that javascript is a competitive 'bytecode' even compared to java or CLI bytecode [1]. Among other things, Bak claims that javascript source is more compact than traditional bytecode.

  [1] about 3/4 into this interview: http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine

Re: Brendan Eich: The infernal semicolon

#35

I wish I had made newlines more significant in JS back in those ten days in May, 1995. I wish Brendan was not as skilled a hacker as he was. It's an amazing achievement that he produced Javascript in such a short time. Unfortunately it ended up having the sorts of flaws that are inevitable with such a timeframe, yet it was "good enough" so that everyone decided it was easier to live with the flaws than break compatib…

If javascript were any worse, it may have been sidelined entirely before it had a chance to improve, and we would be using proprietary application stacks like iOS even more heavily for client side development.

> If javascript were any worse, it may have been sidelined entirely before it had a chance to improve

And we should keep using it in 2012, 17 years later?

Re: Brendan Eich: The infernal semicolon

#36

Earlier quoted context omitted.

I believe he refers to error correction as in it corrects errors in the code -- i.e. the code itself should have semicolons and is fixed through ASI.

Right. To avoid confusion, I updated the post so the sentence reads "ASI is (formally speaking) a syntactic error correction procedure."

Given that these are all formal languages, though, isn't that equivalent to saying that ASI is, formally speaking, part of the language's syntax? It's all just parsers! Apart from the social conventions around them, of course.

Re: Brendan Eich: The infernal semicolon

#38

The key point: "ASI [“Automatic Semicolon Insertion”] is an error correction procedure. If you start to code as if it were a universal significant-newline rule, you will get into trouble."—Brendan Eich

I think the other thing that goes unmentioned is that a single semi-colon on a line in a file would pretty much end this debate.

Perhaps I've worked too much in teams, but surely "path of least resistance" has to factor some, right? I mean, if the choice is add a semi-colon to a line in a file versus asking somebody else to rewrite the compiler to be able to accept it, surely common sense would just be to add the semi-colon.

It doesn't mean that you're wrong, or that your code is broken, or that Crockford is smarter than you... but now you have code that works and compiles and that people can use.

Surely, that's gotta count for something, right?

Re: Brendan Eich: The infernal semicolon

#39
post #33

Heh, I was waiting for this post. Coming in the next 24 hours: - "Why I use minimal semi-colons in Javascript" - "ASI is broken but I like it" Honestly I'm shocked at the defense of this practice (of ASI "abusage"). It speaks loudly to Jacob's (fat@githib) ranking of ego-stroking and showboating over creating readable code, particularly for a library "Designed for everyone, everywhere" [1]. I'm confounded that such a…

> I'm confounded that such an attitude can survive in a large engineering organization like Twitter.

I'm not surprised. A bit disappointed, but not surprised.

Have a look at the original OAuth specification sometime. Note how they misuse the word "key" to mean "identifier". I can't imagine that anyone writing a crypto specification wouldn't know that this would be confusing; I think it's more likely that the person just didn't care. Also, there's the fact that the whole thing could have been written as just a way of getting Basic authentication credentials, rather than making up a whole new authentication scheme.

And then there's the hashbang thing...

Re: Brendan Eich: The infernal semicolon

#40
post #14

Earlier quoted context omitted.

That's a great analogy.

The difference is that if you forget your key, you know that you forgot your key, and you have to actively call the superintendent to have them "save your bacon." With ASI, you might never know that you had forgotten your key.

I agree that it would be nice to have something like "-Wall" that could warn you that you're doing things the "wrong way" but, uh, isn't that what JSLint is?
Post reply on HN