Saturday, April 26, 2008

java'scrypt

Everyone is talking about cloud computing these days; I should add some vapor to the mist.

I began thinking seriously about the topic a bit after April fools day 2004, when gmail was released. I started using gmail shortly therefater. After about 30 minutes, I was convinced that web clients had a long way to go.

It is true that gmail showed the world that you could do far more with javascript in a browser than I or most other people had realized.

Javascript and Ajax have come a long way since then. For an impressive demonstration of what’s possible, see the Lively Kernel, a realization of John Maloney’s Morphic GUI ideas of Self and Squeak, in Javascript. It only works in Safari 3.0 and some advanced Firefox builds, but that situation will improve in time.

Javascript’s performance remains an issue; this will also improve dramatically in the foreseeable future. However, with all the talk about computing in the cloud, I think some caveats are in order.

Many real applications will need to be used offline, and so will need to store state on the client. They are NOT going to be pure server side web applications. Google has finally acknowledged as much with the introduction of Google Gears. Microsoft’s LiveMesh naturally emphasizes this even more.

I say naturally, because Microsoft has an interest in the personal computer, while Google has an interest in taking us to an updated version of X terminals and 1960’s time sharing.Of course, there are other technologies in this space, like Adobe Air. Macromedia (now part of Adobe) saw this coming earlier than most, going back to at least 2003 with its Central project.

With all these pieces in place, we may finally have the underlying elements necessary to build good applications delivered through the web browser.

Why has this taken so long? In theory, Java was supposed to deliver all this over ten years ago. Java started as a client technology, and applets were supposed to do exactly what advanced Ajax applications do today, only better.

Of course, the problem was that Java clients behaved very poorly; rather than fix the client technology, Sun captured the lucrative enterprise business. To understand why Sun behaved that way, why it had to behave that way, read The Innovator’s Dilemma.Maybe I’ll expand on that theme in another post.

The result of Java’s failure on the client was that the entire vision of rich network-enabled client applications was put on hold for a decade. It is now once again coming to the fore, but there are other languages in that space now, Javascript chief among them.

I’m not advocating writing clients in Javascript directly. Javascript is the assembly language of the internet platform (and the browser is the OS). It’s flexible enough to support almost anything on top of it, and poorly structured enough that humans shouldn’t be writing sizable applications in it.

I am not in favor of the attempts to make Javascript 2 be another Java either. Javascript’s importance stems from the existing version’s position in the browser, and from its flexibility. It should be kept simple. Javascript's value increases the more uniformly it is implemented across browsers. A new, complex language will take a long time to reach that point.

People should program in a variety of languages that suit them, and have these compiled to Javascript and HTML (GWT is an example of that, though not one I really like). One shouldn't have to deal with the hodgepodge of Javascript and HTML (broadly defined to include XML, CSS etc.) that constitute web programming today.

I don’t expect native clients to go away any time soon though. They will provide a better experience than the browser in many ways for quite a long time. The advantage of writing in a clean, high level language and platform is that it can be compiled to run either on the “WebOS” or on a native OS.

What one wants to see in such a platform is the ability to take advantage of the network in a deep way - for software delivery and update and for data synchronization. Which brings me back to my theme of objects as software services (see the video), which I’ve been preaching publicly since 2005 ( see my OOPSLA 2005 presentation).

One should be able to write an application once, and deploy it both to the web browser and natively to any major platform. In all those scenarios, one should be able to update the software and data on the fly, run it on- and offl-ine and and monitor it over the network continuously. And all this needs to be done in a way that preserves user’s security. This last bit is still a big challenge.

The technology to do this is becoming available, even though everything takes much longer than one expects. The vision has its root in research in the 1980s, continued in the 1990s with Java (and others, now largely forgotten, like General Magic's Telescript) and will be probably be realized in the 2010s, per Alan Kay’s 30 year rule.

Gilad,Given your background in smalltalk, self and your current involvement with Newspeak, if you were just starting to learn to program which language would you start with? Do you see Newspeak evolving into a language that can be compiled into javascript?

To me, using Webbrowsers and Javascript as the "Virtual Machine" for client applications is one of the worst evolutions in software development. We're using GWT now to re-implement a Java-based client only because customers see the Webbrowser as the best platform nowadays. And, of course, complaining about the application to be unsecure and inefficient. Am I surpised? Not really.

Re: learning to program. I think its important to be exposed to a variety of paradigms. Scheme may be one of the best ways to do this (and has some of the best textbooks ever written as well, like "Structure and Interpretation of Computer programs", and newer ones by Felleisen, Krishnamurthi and co.).

For object orientation, you can't beat Smalltalk or Self.

For concurrency, Erlang is great, though you can now do the same in Scala, which is an excellent place to go as wel, for a combination of OO and functional.

I'd still recommend a variety of others- Prolog, Beta, Haskell, even APL. Each gives a perspective and set of concepts that is enriching.

Once you have these concepts, you can easily grab whatever language is available pragmatically and use it. But I would not start with anything mainstream. Those languages are far too cluttered and messy.

Re: Newspeak. When it's ready for prime time, I will of course recommend it. And yes, I certainly expect to get round to doing a Javascript based implementation.

Of course the current state of affairs is a regression in many ways. The point is that you shouldn't have to reimplement your client. The same source code should just work regardless of the platform you compile to. As I said, we are a quite way from this in terms of security, performance etc. But we'll get there.

Maybe it's time to look beyond the current browser with it's historical baggage and compatibility issues?

The dynamic nature of Croquet fits well with you objects as network services idea. Imagine Croquet implemented in Newspeak ten years from now?

Now something like that would get the punters really excited. My view is that we as an industry are pushing rehashed technology on to users who don't really care for it. The last thing I saw people get excited about was the iPhone.

Proof that innovation can pay.

I've blogged on your presentation on Newspeak. A great presentation by the way:

Re: Croquet. Croquet is pushing technology forward, just as vanilla Smalltalk did years ago. In my view it is not ready for the mass market yet. However, Quaq

http://www.qwaq.com/

is working to change this. I wish them luck.

Re: your review. Well thanks! A quibble or two:

1. The basic FFI with callbacks is working; the higher level convenience layer isn't there yet. We are just calling to/from C (or Objective C) at the moment. Using actors to interface to the outside world was Alan Kay's original plan, but it was far ahead of its time.

2. Types. I haven't given up yet. It's just our lowest priority and a very hard problem. I would like to support pluggable types in Newspeak, and we currently support and encourage type annotations even though they are not checked.

I look forward to the continuation of your review. It's always instructive to see how one's message gets across.

Thanks for another thoughtful post. I'm left intrigued by your comment wrt Google Web Toolkit. What about it don't you like? I've found it solves many of the very problems you describe and am hard pressed to find much to dislike. The deferred binding/multiple permutations of compiled output seemed at first like an inelegant hack, but turns out to be a quite well suited for the problem it solves and the environment in which this stuff ends up running.

Morgan is right in that sense. Java was aiming at such a thing for the web. I have tried my couple of large enterprise applets and they never took-off. Eventually, swing based applets became better, but poeple had already thrown it to dust bin. I still think it might be just a niche set of customers who would be interested in such a technology if it supersedes applets. Write once run everywhere/every OS (Java's view) is still not a necessity to many for e.g those who use MS products.

When I bought my computer and I didn´t know how to use java graphics, so I decided looking for information in a webside and I found an useful information that helped me a lot.. Now I am interested in to do the best investment and I found a webside very useful and interesting called costa rica investment opportunities , I think it´s a very wonderful site.