11 thoughts on “Activating the web: One programming language or many?”
Ugh, you’ve totally swallowed the MicroSoft pill — your assimilation is complete.
1. MicroSoft is not the only multi-language VM in town — take a look at all the languages that are being dropped on top of the Java VM, which is commonly regarded as the best VM around (full disclosure: I don’t even use Java).
2. MicroSoft has abused the developer and user communities at large too badly to regain their trust. Sure, their are A LOT of MS developers out there but there are a ton more that are not MS (or exclusively MS) developers. Last I checked, the web was still dominated by the LAMP stack. Sure, Silverlight is cross platform… however, MS has demonstrated that they can’t even make PowerPoint or Outlook/Entourage work consistently on Windows and MacOS.
3. MicroSoft has a clear bias (and probably should) on the success of their Windows platform and, likewise, the downfall of other platforms. What possible motive is there for providing a solution that works equally well on all platforms? For example, if MS were to have two tasks to consider working on — (1) fix some display problems for Linux and (2) improve the performance for Windows — which would get priority? The *real* answer isn’t even important — the outside world “knows” that MS will work on #2. They just don’t play well with others.
Your views and commentaries used to be much more balanced. I miss that.
Gee, thanks Google. I feel about this the same as I felt about AJAX.
I am very suspicious of Google’s intentions. I bet there is no capability to block ads. Are they just trying to create an alternative to Silverlight and Flash?
Besides, any new concepts will be picked up right away by Firefox, and in a few years by Microsoft.
> the Java VM, which is commonly regarded
> as the best VM around
Since long before joining Microsoft, I have been noting that the multilingual capabilities of the JVM are bolted on, not built in.
> Last I checked, the web was still
> dominated by the LAMP stack.
And that’s part of my point. There’s a ton of server-side Python and Ruby. Bringing those languages client side is an interesting way to leverage those skills and reflexes.
Opening up such choices is another aspect of the continuum of access styles (http://blog.jonudell.net/2008/08/27/the-continuum-of-access-styles-in-the-emerging-microsoft-cloud/) I mentioned the other day.
The DLR is just as “bolted on” as anything comparable on the JVM. Where DLR has an advantage is that it’s funded by Microsoft, who has multiple different language folks working on it, and that it provides a unified version of what many JVM languages develop and cultivate independently. It is not built into CLR in any way, and even if it were shipped with .NET it still would be simply part of the runtime libraries.
The JVM (in the form of HotSpot), on the other hand, is already essentially a dynamic language runtime under the covers. Any code loaded at runtime is enlisted in dynamic optimizations, which means that e.g. JRuby just needs to present Java bytecode and it will be optimized like any other piece of Java code without any of the tricks that are essential in the DLR. Where it’s more difficult than it should be is in the fact that there’s this nasty static-typed layer wrapped around the JVM (i.e. Java), but optimized dynamic invocation work (hopefully to be in Java 7) will eliminate that issue as well.
You said it better, Charles, thanks. I guess we could say that multilingual capability, for static and more recently for dynamic languages, has been a higher priority for the CLR than for the JVM, though I know the priority is changing for the JVM.
How these capabilities can and should be used in general, and specifically both in the cloud and on peers — these questions interest me a lot.
“How these capabilities can and should be used in general, and specifically both in the cloud and on peers — these questions interest me a lot.”
I think this is the key issue, yes. So far there is one reasonable RESTful client application: the browser, generally. (Well, and email clients, arguably.)
Good RESTful clients should be more secure than the browser, more “rich” than the browser, and more easily programmed than the browser (i.e. easier and more expressive than ajax). Good RESTful applications should not require “one-off” programming on the client side. Nor should they expect all the client components to be developed in any single language, or run in a single runtime container.
One interesting way to bring multiple language to multiple back-ends would be PyPy.
It is a language agnostic toolchain where you ‘describe’ an interpreter in RPython and it can generated them for a multitude of backends (.NET, C, JVM).
There is already talk of a Tamarin backend and V8 one would probably be possible.
On the front-end there are already Python and Smalltalk interpreters. Ruby and others would also be well possible.
Supplying a VM in the browser does enable all sorts of client-side, desktop-like behavior… but has anyone else begun to notice that page load times are increasing as all of the script language gets loaded with the page?
Next up: browser code which virus-scans dynamic languages on the fly (or do those already exist)?
Well, the whole point of sandboxing is that you don’t need virus scanning…