Infrequently Noted

I'm not sure how long it was b0rked, but the online ShrinkSafe app is back up and working.

Dojo's has as long a history as any chunk of JavaScript in wide use, and it's easy to forget how long the road has been and how far the project has come. Will of the Lucid Desktop project has put together a code_swarm visualization of the project's history to date. Lots of fun to see old friends appear and think back on when what happened:

Thanks, Will!

A relatively light-on-data article is up at Slashdot right now, and it casts aspersions both on the IBMers who contribute to Dojo and on the Foundation itself based on the Free Software party line that all software patents are inherently evil.

I won't address the background point regarding software patents here. I'll only to say that reasonable people can disagree on this, particularly when it comes to proposed solutions. What I would like to focus some attention on is the background that this patent filing is made against.

IBM has executed a CCLA with the Dojo Foundation. This agreement gives Dojo (and the rest of the OSS community) a license to whatever patent rights may be embodied in contributions of code. While IBM may file patents on things they build and contribute to Dojo, there's no risk to any users regarding use of that code or "submarine" issues of patent infringement. As a result of the Dojo Foundation's insistence that ALL code come with CLAs, Dojo is more trustable in terms of IP than most of the JavaScript you can choose to use. A similar patent claim in a less rigorously developed toolkit would indeed be apocalyptic, but the Dojo community has adopted a mature process for dealing with IP that both makes the concerns plain and then works to eliminate them, step-by-step. That's what licensing agreements are, after all: links in the chain that together help you trust that your anchor is indeed set.

It's clear to me that IBM filed this patent fully aware that they were giving away all follow-on rights to enforce it in anything but a defensive way for the benefit of the Foundation and users of Dojo. After watching IBM counsel decimate SCO in court, does anyone in the OSS world really think that IBM's lawyers are fools? And if so, to what end?

It's sad that Slashdot hasn't, for a decade of coverage of IP issues, learned that licensing is harder than the zealots would have you believe and that malice isn't always the intent of those who participate in communities with a commercial interest.

The good news here, of course, is that IBM is just as generous today toward the OSS and Dojo communities as they were yesterday. We have the legal documents to prove it.

No less than the Times has chastised the Chrome team's marketing efforts, noting unsubtly that for months now we've been burying the lead: Chrome's killer feature isn't that it's got an awesome UI (it does) or that it supports new web features...no, the real story that we haven't been telling well is that it's wicked fast.

I'm sure all the blags will be a-twitter with this shortly, but Chrome 2.0 is now out to everyone, and it's even faster. Yes, V8 got even more polish (new compiler infrastructure FTW!), but the big speed news from my perspective comes from other parts of the browser. Chrome 2.0 moves fully away from the Windows networking stack to Chrome's faster networking infrastructure and includes changes to memory allocation that make the DOM go like hell. There's lots of great feature work in 2.0, of course, but now's not the time for us to bury the real story: Chrome, fast as it was, just got even faster. Thanks to silent auto-update, it'll even make the web faster faster.

Bam!

The ES working group is hard at work on "Harmony", the goals of which are significantly more sane than previous attempts to build a new language from JavaScript. Namely, they're being careful to be able to express things in new syntax based on old syntax. This is referred to as "de-sugaring". Many new bits of syntax will be expressed in old syntax in a resulting spec, and so it will be with any new lambda syntax.

One of the things I find most persistently annoying about the language as we have it is the verbose and wordy way of saying "build me a new invokable thing". Since JS builds dynamic scopes based on on functions, this is particularly annoying when writing event handlers, callbacks, and arguments to forEach and friends. Needless to say, these are the things we do all the time in JavaScript. If there was anything that deserved syntactic sugar, this is it.

This brings us to "lambdas". Languages like Ruby have a great syntax for expressing "a thing you can invoke" in a terse way. Python has something along these lines based on the keyword lambda, but Guido insists on keeping them neutered based on (AFAICT from in-person discussions) a dislike of functional programming. Java is dangerously close to getting useful closures but it's so syntactically handicapped that it'll probably be another decade before the masses rebel and demand a terse way to say what they mean. Or maybe they'll all have just defected to JRuby. For most of these languages, being able to say "here's a new invokable thing" tersely is a Nice To Have feature. No real-world program will be slowed down by the size of a keyword. Indeed, Java makes you do so much work for the compiler that it's practically taken as a badge of honor that you have to type it all out over and over and over.

JavaScript is different. Unlike nearly every other language, the terseness of JavaScript code is a key determinant in the performance of a web application. The bigger your scripts, the slower your app loads. It's as simple as that.

It's a crime, then, that we still have to type:

node.addEventListener("click", function(evt){ /* ... */ }, false);
// or
[/* ... /].forEach(function(i){ / ... */ });

The syntax for "an anonymous invokable thing" should be a lot shorter given how much exercise it gets in the real world. What real-world script authors don't need is something other than "a shorter way to say function". Anything different than this isn't strictly useful. Anything that requires you to use a more wordy syntax to name arguments is a failure, and anything that uses a name longer than the shortest possible thing just re-introduces that bug that needs fixing in the first place. There have been proposals at the ES working group to date regarding "lambdas" and most assume that they will be something that serves to make implementer's roles easier when it comes to de-sugaring but fail in one of these ways. Folks who write actual scripts should start speaking up and telling the Harmony working group what needs to be clearly and un-ambiguiously said:

Don't fuck with the semantics of function, just let me stop typing it so often

What might a better syntax for function look like?

The best that Erik and I could come up with that is relatively unambiguious for parsers, doesn't introduce hard-to-type characters on certain keyboard layouts, and doesn't mess with the semantics of function(){} is this:

// empty function body, zero arguments
var lambda = #(){ /*... */ };
// empty function body, arguments list elided away
var lambda = #{ /* ... */ };
// we can re-write the previous examples as:
node.addEventListener("click", #(evt){ /* ... */ }, false);
// and
[/* ... /].forEach(#(i){ / ... */ });

The long history of the word "lambda" coupled with the different interpretations that various languages place on them make using the word "lambda" to say "a short name for something you can invoke" particularly loaded. Perhaps instead we should just call this new syntax that crams a lot of meaning into a short "keyword" something else entirely.

"Cramdas", anyone?

Update: ...and James Padolsey makes it so!.