Semicolons, Douglas Crockford, Danny Goodman and Anders Hejlsberg
Okay: there is now a technical reason to use semicolons in JavaScript. According to Yahoo! JavaScript Architect, Douglas Crockford in “The JavaScript Programming Language” (Part 4), when an error is encountered in the script, the browser will replace line breaks with semicolons and try again. Immediately to me this behavior associates with recovering from an exception. In C# it’s a performance no-no to write code that depends on throwing an exception. It would be crazy to write code such that every line throws an exception! But that is exactly what I’ve been doing for almost ten years based on some long-gone edition of the JavaScript Bible by Danny Goodman.
Perhaps he would deny it, but I’m sure Danny Goodman wrote that semicolons are “unnecessary.” I took that information and ran with it! My assumption was that the use of semicolons was matter of blind habit—very similar to old folks who hit the space bar twice after each sentence. My effort was to distinguish JavaScript from Java and C and not using semicolons was one (ignorant) way of doing this.
Douglas Crockford very adroitly and articulately distinguishes JavaScript in his video series (mentioned above). From the new teachings of Crockford, it is clear why Anders Hejlsberg is adding lambda power (anonymous functions or a function() function) to the next version of C#—lambda has been in JavaScript for years and Danny Goodman had no idea of this realized in print…
You C# experts may say, “Hey! C# 2.0 already has anonymous methods! That’s your anonymous function!” Well, both of us need to read the three part series by Eric Lippert called, “Lambda Expressions vs. Anonymous Methods.” Douglas Crockford, by the way, points out that JavaScript is not a “type-free” language. JavaScript types have been inferred for years—only now, with C# 3.0, does Microsoft make the type inference concept something to shout from the rooftops.
Comments
Danny Goodman, 2007-02-14 08:46:47
In the early years of the language, semicolons at the ends of statements were certainly treated as optional. Even Brendan Eich wrote about the original language design issues in his foreword to the 4th edition of my JavaScript Bible (the 6th edition is coming soon): "But insisting on Java's class and type declarations, or on a semicolon after each statement when a line ending would do, were out of the question...."
You can also check Section 7.9 of the ECMA262-3 standard for its recommendations on Automatic Semicolon Insertion.
That said, there have been rumblings for years that a future iteration of the language may require semicolons to terminate every statement. In light of that possibility (and possible performance issues with humongous scripts), all code examples in my JavaScript-related books for the last few years have promoted the use of explicit semicolons at the ends of statements. I've been using them in my own coding for so long now that I couldn't tell you when I started doing so.
I also can't tell from your article for certain, but you imply that the JS Bible edition in your recollection didn't cover anonymous functions. The subject has been in there since the 3rd edition of 1998. To my own recollection, the anonymous function wasn't in the language in the mid-1996 timeframe of the 2nd edition, making it difficult to have any "idea of this realized in print..." at the time. The language evolved rapidly over its first few years of life. Relying on an outdated edition as the last word on the subject isn't something I recommend.
rasx(), 2007-02-14 17:22:01
First, before I write anything, let me say that is an honor actually reply to Danny Goodman himself! It would be great to see you and Douglas Crockford sit down and talk JavaScript. You may have noticed his regard for books on JavaScript...
Now, there is no assertion here that anonymous functions were covered by your work. It is this "lambda" buzz word that stands out...
Do you have a Blog?
Danny Goodman, 2007-02-15 16:20:17
> Do you have a Blog?
Not for scripting, but for my primary passion at the moment, email safety for everyday users (http://spamwars.com). The two worlds collide occasionally as crackers try to obfuscate/encode scripts in malware delivery web sites (destinations of links in various spam/spim messages). I guess they think they're being clever, but it's child's play to decode and uncover the malware hosts.