Lambda the Ultimate

It's sad that I can create a far richer user experience in MS Access from 10 years ago than I can over the web today (in less time with the same amount of effort).

Debatable. Can't use an Access app from anywhere in the world, and I count that as a big plus in the user experience column. Your point is well taken though. With MS's new Silverlight, Flash and ActionScript, Mozilla's push with XUL+JS 2, and a few other endeavours, perhaps you'll get your wish.

of cheap high-bandwidth, low-latency connections.

No amount of PLT or platform cleverness will make a pleasant user experience out of a 56k dialup line. :)

No amount of PLT or platform cleverness will make a pleasant user experience out of a 56k dialup line. :)

I think you'd be surprised. If you design the GUI architecture properly, you can get the bandwidth low enough that people will barely notice it. There are a few tradeoffs involved of course, and noisy connections will definitely cause latency issues. Take a design lesson from MMORPGs: predict client-side (untrusted), then reconcile conflicts server-side (trusted). If it works for high-bandwidth, highly distributed and interactive 3D environments it can work for relatively lower-bandwidth desktop-like interaction. :-)

MMORPGs are a special case: a lot of the bandwidth saving comes from distributing the client application on a DVD..

I remember Berlin a project to do client server GUIs, which tried to put more intelligence in the display part to reduce the bandwidth used and the latency, the problem is that this creates a high coupling between the display part and the application ..

MMORPGs are a special case: a lot of the bandwidth saving comes from distributing the client application on a DVD.. [...] [Berlin] which tried to put more intelligence in the display part to reduce the bandwidth used and the latency, the problem is that this creates a high coupling between the display part and the application

Yes, that's it exactly. Except nowadays in the world of pervasive VMs, updated code and/or app/display server dependencies can be downloaded and executed on the fly; after the initial download, network communication is fast.

Unfortunately, .NET is the only widely deployed VM that comes somewhat close to this safety goal with it's notion of the AppDomain. Even the AppDomain is insufficiently isolated however, as malicious code can still mount DoS attacks against the memory subsystem, and the "scheduler". I've written about .NET's limitations in this regard elsewhere, and I hope to follow this up soon with a post on the minimal features required of a true secure common language VM that can do the above (hints are in that post though).

I agree with everything you said, especially the dumb terminal observation. But as naasking pointed out, it's all about deployment.

Silverlight seems to change the landscape a bit though with support for C#, JavaScript, Ruby, Python, Java, or any .NET language that can be hosted in the Silverlight CLR sandbox.

While I'm not the biggest fan of prototype based object models like the one Javascript uses, I couldn't agree more with the comments about the platform.

But there are more things that need to be solved as well. One is tool support, its been a while since I've done web work but I've yet to find a Javascript/HTML editor that provides as many productivity gains as Eclipse JDT and Visual Studio's IDE's for VB, C++, and C#.

Lets also not forget usability issues as well. 4 of the 5 easiest places to reach with a mouse are already taken by the browser's control bar and the operating system's task bar.

In happier news, recent VMs and compilers for JavaScript are getting their acts together, adding type inference and JIT compilation and nice garbage collection. The future will always be profoundly sub-optimal, but a lot of work will go into polishing it.

The only sad/happy (depends on your perspective) thing is that most functional languages (OCaml, SML, Haskell, and all the forgive-me-not-to-mention-them ones) can do most of the things praised in this essay.

I cannot help myself but view that all the static/dynamic flame war (I hope I won't start another battle) has actually been static(C++, Java) vs. dynamic. Somehow, I feel that the praise that dynamic and scripting languages recieve mostly originates in their succinctness (no need to declare types - also a feature of some static languages) and their runtime reflexivity (and the ability to alter the code/behaviour at runtime - I personally haven't yet seen many programming challenges that can be significantly better and faster solved using reflectivity), which are a huge gain compared to Java and C++, but not necessarily better than ML.

While the code examples are in JavaScript, Joel is quite clear in his essay that any language with first-class anonymous functions wins in the same way, and that thinking functionally is how you come up with Google's (in?)famous MapReduce. He (again, correctly) complains of the poor support in Java and C++ for the paradigm. Not once does he say anything about static this or dynamic that—I'm pretty sure that he knows better. Like 99% of everything Joel writes, I think his post presents the crystalline beauty of the functional style in a very accessible way.

is the complete lack of support for HOFs, other than via the artifice of writing a classes which implement a "doit" method. (Many of Java's issues would be more tolerable if a decent preprocesser were part of the language definition).

C++, at least, has function pointers and operator (), and such can fake combinatorial HOFs reasonably well without too much extra syntax. (OTOH, environment capture is still a big issue; as has been pointed out, a lack of GC makes managing closures properly difficult).

Closures for the Java Programming Language

Hi Sergey,

If you're interested in GWT, but prefer Python over Java, there's a project called pyjamas, which is essentially a pythonized clone of GWT. Disclaimer: The GWT team (of which I'm a member) has no relationship to pyjamas.

It sounds like it might be down your alley. That said, I'm not sure how pyjamas compares with our optimizations. We're aggressive with whole program transformations that would seem difficult to do in python. In fact, GWT doesn't support dynamic class loading for that very reason.

Thanks. I did find pyjamas soon after I wrote that blog post, and it looks nice. What I was trying to do is quite different, my aim is not to override javascript semantics but only reuse python syntax and make it possible to implement server-side and client-side code in the same module. Not sure about Pyjamas, but at least GWT could not be mixed with JS libraries like YUI or MochiKit etc. My module seems to interoperate with it just fine.

GWT is awesome with it's optimizations. Nothing of that kind in my implementation =) (Not sure about Pyjamas either)

You should be able to use JSNI to embed any javascript library component you need. For example, this IBM developerWorks article demonstrates embedding an ActiveWidgets control inside a GWT application. Additionally, we are working on a javascript "import/export" mechanism that would provide better automation for that process.

If there's a specific problem you're having, or any insights you'd like to share, please let us know. :)

I am not sure just how relevant it still is, but check out our original discussion of GWT...

Me? I am still waiting for the Google DSL I suggsted long ago (which will probably be called the GPL... as in "Google Programming Language"...)

Thanks for suggestions, all of this looks quite interesting.

The internet is a hostile environment, and having a distributed OS heads straight into issues surrounding security and trust. Though there are possible solutions, they do require cooperation (or conspiracy) between a large number of parties to get things up and rolling.

The main thing I like about http/html based appls is the loose coupling. And I don't have to worry about installation issues (e.g. some user blaming a hard disk crash on my software simply because it was the last thing installed on the machine). And I don't have to worry about what OS or version they run.

And I don't have to worry about what OS or version they run.

That seems odd to me. Don't you have to worry about what e.g. strange internationalized version of Opera they are running? (Or do you just aim for IE6+ and say everybody else can jump off a bridge?)

If you adapt some of these platforms, you DO have to worry about the browser or OS your customer runs.

Some of the platforms proposed--Silverlight, the new Adobe stuff--might not work on your browser or OS. MS appears to be supporting Silverlight on Windows platforms, regardless of browser (including Firefox--MS has done much to support Firefox on Windows of late). MS also will likely support Macs running Safari. MS certainly will not support Firefox on Linux, Konquerer on Linux, or anything else for that matter on any OS other than Windows (XP service pack 2 or Vista) or certain flavors of MacOS. There's always Mono; but how quickly they can track MS' changes, and/or stay clear of legal issues, remains to be seen.

Adobe has less reasons to be platform-hostile than does MS--they are not an OS vendor after all. OTOH, their support for Linux has been spotty in the past.

AJAX, for all its warts, works on pretty much every modern browser+OS combination.

JavaFX is a bit of an unknown quantity.

There is one player that can have an influence on this, but whom we haven't heard from yet: Google. Most if not all rich client apps they've done have been using the open-source kit. They've got the in-house software expertese, as well as the market presence, to influence this sort of thing should they choose.

There is one player that can have an influence on this, but whom we haven't heard from yet: Google. Most if not all rich client apps they've done have been using the open-source kit.

I'm employed by Google, but I am only speaking for myself.

If you adapt some of these platforms, you DO have to worry about the browser or OS your customer runs.

Google Web Toolkit supports all the major platforms out of the box. We isolate platform specific code (typically embedded javascript) into different classes using a rebind strategy. For example, the DOM class is backed by browser-specific impl classes, only one of which is selected per webapp permutation at compile time.

The technique is a pretty important differentiator for GWT in that it allows us to automatically build specialized, lean permutations of your webapps for each browser (e.g. webapp-ie6.js, webapp-ie7.js, webapp-ff2.js, webapp-safari.js, webapp-opera.js, etc...). Typical webapps send all the differing browser-specific code to each and every client, regardless of their actual browser.

</shameless advertisement>

That's similar to what haXe is doing.

First, Javascript isn't supported via plugin, typically--it is, as you say, built into the browser. All the major browsers support it (some version thereof) out of the box. Unlike Java (until recently), Flash, and anything .NET, there are long been good open-source implementations of Javascript.

An interesting question, now that Sun is finally releasing the whole Java shebang under the GPL, is how long before certain browsers (mainly Firefox) ship with Java built in? That seems a no-brainer.

And then, there is the inertia problem. Few shops do web apps in Scheme or ML or Haskell for the same reason that few shops write embedded systems, shrinkwrap software, or client-side stuff in these languages. With web apps, there is a chicken-and-egg problem; browser vendors (including Mozilla) are unlikely to embed languages in a browser without demonstrated use; and app developers certainly aren't going to write client-side code in a language that most browsers don't support. Getting people to install plugins for things like Flash or Java is enough of a hassle.

In other words, the reasons are primarily social and not technical.

An interesting question, now that Sun is finally releasing the whole Java shebang under the GPL, is how long before certain browsers (mainly Firefox) ship with Java built in? That seems a no-brainer.

Why would Mozilla introduce a huge dependency for something that is largely irrelevant in the browser? Did applets make a comeback when I wasn't paying attention?

Did applets make a comeback when I wasn't paying attention?

Combine Java Kernel with JavaFX and the answer may be, "yes".

Lots of things are possible in the future, but last time I checked applets didn't make a comeback.

If the comments over at Javalobby.org and TheServerside.com are any indication, then JavaFX has an uphill battle.

But it's definitely not a no-brainer for Mozilla to make a decision to start shipping Java.

but why do you think that Java has apparently failed this particular niche (client-side web app)? Java thrives elsewhere, but this niche was seen originally as Java's "sweet spot".

1) Issues with the language itself (syntax and semantics)?
2) Performance issues--VM startup time, applet running time, poor behavior of early GC technology?
3) Other broswer integration/user experience issues--need to download and install a plugin, ugly widgets (that look different from native widgets), etc.
4) Security issues?
5) Licensing issues, other supplier issues from Sun Microsystems?
6) Interference from Microsoft?

• Immaturity of the Java system itself
• Immaturity of client systems (bandwidth and performance considerations)
• no Flash-like installer
• versioning and updating issues

And I would say that (1) on your list might have been an issue too. Content authors don't want to monkey around with Java's heavyweight syntax.