Last week I was at lang.net 09 and DSL Dev Con. It was great fun, as always. The best talk was by Erik Meijer. Use the link to see it - but without live video of Erik in action, you can't really understand what it was like. Such is performance art.
I also gave a talk, and there were many others, but that is not the point of this post. Rather, this post was prompted by one specific, and excellent, talk - Lars Bak’s presentation on V8. Lars clearly enjoyed his visit to the lion’s den; more importantly, perhaps Microsoft will finally shake off their apparent paralysis and produce a competitive Javascript engine.
That, in turn, will make it possible to distribute serious applications targeting the web browser, with the knowledge that all major browsers have performant Javascript engines that can carry the load.
It’s all part of the evolution of the web browser into an OS. This was what Netscape foresaw back in 1995. And it is a perfect example of innovator’s dilemma.
Innovator’s dilemma applies very directly to programming languages, and Todd Proebsting already discussed this back in 2002.
To recap, the basic idea is that established players in a market support sustaining innovation but not disruptive innovation. Examples of sustaining innovation would be the difference between Windows 2000 and Windows XP, or between Java 1.0 thru Java 6.
Sustaining innovations are gradual improvements and refinements - some improvement in performance, or some small new feature etc.
Disruptive innovation tends to appear “off the radar” of the established players. It is often inferior to the established product in many ways. It tends to start in some small niche where it happens to work better than the established technology. The majors ignore it, as it clearly can’t handle the “real” problems they are focused on. Over time, the new technology grows more competent and eats its way upward, consuming the previous market leader’s lunch.
We’ve seen this happen many times before. Remember Sun workstations? PCs came in and took over that market. Sun retreated to the server business, and PC’s chase it up towards the high end of that market, until there’s nowhere left to run.
In the programming language space, take Ruby as an example. Ruby is slow, until quite recently lacked IDE support etc. It’s easy for the Javanese to dismiss it. Over time, such technology can evolve to be much faster, have better tooling etc. And so it may grow into Java’s main market.
Don’t believe me? Java in 1995 was just a language for writing applets. It’s performance was poorer than Smalltalk’s, and nowhere near that of C++. There were no IDEs. Who's laughing now?
Javascript is an even clearer case in point. It was just a scripting language for web browsers. Incredibly slow implementations, restricted to interacting with the just the browser. No debuggers, no tools, no software engineering support to speak of.
Then V8 came along and showed people that it can be much faster. Lars’ has doubled performance since the release in September, and expects to double it again within a year, and again 2-3 years after that.
Javascript security and modularity are evolving as well. By the time that’s done, I suspect it will far outstrip clunky packaging mechanisms like OSGi. This doesn’t mean you have to write everything in Javascript - I don’t believe in a monolingual world.
Tangent: Yes, I did spend ten years at Sun. A lot of it was spent arguing that Java was not the final step in the evolution of programming languages. I guess I’m just not very persuasive.
The web browser itself is one of the most disruptive technologies in computing. It is poised to become the OS. Javascript performance is an essential ingredient but there are others. SVG provides a graphics model. HTML 5 brings with it persistent storage - a file system, as it were - only better. You may recall that Vista was supposed to have a database like file system. Vista didn’t deliver, but web browsers will.
This trend seems to make the traditional OS irrelevant. Who cares what’s managing the disk drive? It’s just some commoditized component, like a power supply. We can already see how netbooks are prospering. This isn’t good news for Windows.
Of course, you might ask why Microsoft would go along with this? Is IE’s Javascript so inadequate on purpose? Maybe it is part of the master plan? Well, I don’t believe in conspiracy theories.
It does look as if Microsoft is facing a lose-lose proposition. Making IE competitive supports the movement toward a web-browser-as-OS world. Conversely, if they let IE languish, as they have, they can expect its market share to continue to drop.
However, you cannot stop the trend toward the Web OS by making your tools inferior. You can only compete by innovating, not by standing still.
I wouldn’t count Redmond out just yet. They have huge assets - a terrific research lab, armies of smart people in product land as well, market dominance, and vast amounts of money. They also have huge liabilities of course - and those add up to innovator’s dilemma.
In any case, for language implementors, it’s clear that one needs to be able to compile to the internet platform and Javascript is its assembly language. Web programming will evolve into general purpose programming, using the persistent storage provided by the browser to function off line as well as online.
As many readers of this blog will recognize, this sets the stage for the brave new world of objects as software services. I hope to bring Newspeak to the point where it is an ideal language for this coming world. It’s a bit difficult with the very limited resources at our disposal, but we are making progress.
The entire progression from conventional computing to the world of the Web OS is taking longer than one expects, but is happening. The time will come when we hit the tipping point, and things will change very rapidly.
A place to be (re)educated in Newspeak
Subscribe to:
Post Comments (Atom)
17 comments:
If the Web OS is inevitable, how do new languages enter the fray? Compile to javascript or did you have some other backdoor to the browser in mind?
The Silverlight (argh) does not work for me using the mono implementation. However, embedded in the javascript
http://langnetsymposium.com/2009/talks/StartPlayer.jshas links to the .wmv versions of the talks.
dmi: Yes, compilation to JS seems inevitable.
James: sorry about the silverlight. The lang.net site has links to wmv if that is any better.
Thanks for the wmv links James.
Hum, "the world of the Web OS is taking longer than one expects": oh, yes. I have read (first) papers talking about Web OS around 1997-1998.
"The time will come when we hit the tipping point, and things will change very rapidly": I agree too. IMHO, the introduction of VM on the client-side, within browsers, is quite a step forward.
This being said, frontiers become fuzzy as Java and JavaScript become closer. I have written a post about it: A false piece of news may become real as Java and JS move closer (I reference a piece of news saying that Google has already used JS on the server-side).
But today, while JS landscape is expanding, Java move closer to the client-side too (better startup-time for example). Some Swing desktop applications are re-invented to follow the browser trend (following somewhat, here, Adobe Air), see my post Swing browsers - other interesting DSL Swing projects to follow.
So, there is quite a double move. Competition is here. Well, JS has big advantages, being already into the place, and pervasive into browsers. However, I hope the competition is still open.
I couldn't agree more. There's nothing else I can add to this post except a quote from Alan Kay.
"I believe that the only kind of science computing can be is like the science of bridge building. Somebody has to build the bridges and other people have to tear them down and make better theories, and you have to keep on building bridges."
you could have c# compiled to javacript via jsc compiler
http://jsc.sf.net
"Of course, you might ask why Microsoft would go along with this? Is IE’s Javascript so inadequate on purpose? Maybe it is part of the master plan? Well, I don’t believe in conspiracy theories."
But can you believe that smart companies are capable of acting in their own self interest?
The development of DHTML libraries that workaround the "Important Exception", as IE is known among web developers, was necessary and sufficient to evolve javascript into the "web's assembly language," as Dan Ingalls called it. Javascript is what it is because of its ability to manipulate the DOM in all the major browsers. Ubiquity took extra years because of IE.
Reasonable minds can speculate on whether IE is an Important Exception as the result of chance or intent. Less plausible would be speculation about whether DHTML incompatibilities have slowed down progress in web apps, or whether it is in Microsoft's interests to slow down such progress.
Hi Gilad,
I found the V8 talk by Lars really fascinating. It left me with a few questions that perhaps you can shed light on:
1. Lars mentioned that he didn't see the need for byte code. Object literals in Javascript (an object as an hashmap), have a pretty terse syntax and should be easy to parse. So can Javascript be considered a universal "assembly" language of sorts for OO languages?
2. If so, is Javascript more compact and hence faster to download then the equivalent byte code?
3. Do you think using Javascript as an intermediate form, before compilation to machine code at runtime will ultimately be a faster approach then using byte code?
4. If so could languages like Ruby, Phython etc or perhaps even Smalltalk/Newspeak, gain better performance by using javascript as an intermediate instead of byte code?
I guess it comes down to the time taken to compile Javascript versus the time taken to interpret byte code. V8 has taken the much simpler approach of compiling everything to machine code. Could this prove quicker then interpreting and then having to compile byte code later anyway?
It would be interesting to hear your take.
Thanks Paul.
Hi Gilad,
yes Erik's and Lars' talks were really good. But your own presentation of Vassili Bykov's presentation is masterful too. You manage to convey the essence of what's so cool about a dynamic reflective implemented-in-itself language and IDE in 25 minutes. Its superb.
Paul,
in response to question 1, yes, to some extent. But there are things JavaScript doesn't do that Smalltalk does and that Smalltalk IDEs rely on. For example JavaScript has no reification of execution state which makes it hard to write debuggers in JavaScript itself, something that is at the heart of Smalltalk IDEs. But this is more about the run-time system than the language. Think of JavaScript as a syntax on an object model. The important thing is the object model and JavaScript's is in many respects powerful and dynamic and a superset of most of what you need. But then so is Smalltalk and so is CLOS.
2. Depends. Depends on the bytecode set and on whether one compresses JavaScript code. Most bytecodes in the Smalltalk/Self family are typically more compact than source because they're approximately < 5 bytes per token (1 bytecode and 1 object reference per token, with the high static frequency object references encoded in bytecodes). But compaction tricks can be applied to either and so in some information-theoretic sense they're equivalent; given a well-engineered compressor two identical programs expressed in source and bytecode would compact to the same end result.
3. No. The speed comes from the run-time system not from the use of source, and the run-time system's performance is a function of the object model and the quality of the engineering (optimizations) applied to it. So one should be able to get equal speeds using bytecode or JavaScript. The thought experiment is simply to propose a bytecode set that captures JavaScript. Obviously one can get the same speed out of both. No fast JavaScript or Smalltalk or Ruby engine will interpret either bytecode or source. Instead it will compile it (dynamically) to machine code and use lots f tricks to make that machine code go fast.
4. No. And for the moment they will lose out in debuggability and support for development (for the points mentioned in 1.). But that's not the point. V8 is a fast JavaScript (and it will get faster). And in the limit it should be able to execute Smalltalk as fast as any other well-engineered Smalltalk engine.
But V8 is in the browser and it or the equally performant implementations it provokes will be in all browsers pretty soon, which certainly won't be the case for Smalltalk and Ruby VMs. So if one wants to reach the web one needs to compile to JavaScript because one has instant ubiquity.
In response to your last point only slow VMs interpret anything. For 25 years now (the Deutsch-Schiffmann Smalltalk JIT was written in 1983/1984) fast dynamic language VMs have executed machine code. Yes, overall eliminating bytecode can be simpler, but if one already has a complete system that uses bytecode implementing a bytecode-to-machine-code JIT can be simple too.
My real point is that the important thing about JavaScript and V8 is not the JavaScript syntax or the source-to-machine-code compilation route; what's important is the high performance of V8 and the ubiquity of JavaScript. Turing was right in his equivalence principle, but there are no infinite tape readers in web browsers.
Hi Paul,
Eliot saved me the trouble of responding, but I will anyway.
Each environment has different constraints. For instance, parsing source is never free - but given that a web browser has to parse JS anyway, it sort of is for a web browser.
Using source as a wire format can be very compact, and has the advantage that it preserves more of the program structure. In some cases that actually helps - in Java, the JITs spend a lot of effort reconstructing structure that existed in source, but wa slost in the byte code. In any case, the idea is not new - Michael Franz argued this in the mid-90s.
Dispensing with byte code increases memory footprint (machine code is not compact) but makes the system very simple. Given the need to ship a robust product in a hurry, that's a plus in the V8 scenario.
JS programs are still pretty small, and embedded in web browsers that are already memory hogs - so minimizing code footprint is not so important - for now.
Machine code gives you maximal speed - once you compile. In a high latency setting like a web browser, compiling gets lost in the overhead of shipping the bits. Especially if compilation is not too elaborate.
These trade offs may change over time. At the moment, they make sense for V8.
Compiling other languages to JS is necessary for web distribution. It may not yield maximal performance - at least not yet.
But as long as performance is reasonable, distribution considerations will dominate.
I and others (such as Erik Meijer) have made the point that JS is the assembly language of the internet platform for several years now. Lars talk just shows you that it's already here.
Hi Eliot, Gilad,
Thanks. My degree is in telecommunications, and from the little I can remember about information theory, what you both say makes a lot of sense.
@Eliot
I assume by "reification" you mean the spaghetti stack and other 'reflective' plumbing that you get in Smalltalk and you don't get in Javascript?
This stuff aside, then I can see that the information content of Smalltalk byte code and Javascript is roughly the same.
So the determining factor when it comes to speed is how fast the VM can "process" the information. Which like you say comes down to the VM implementation.
@Gilad,
I guessed that the network latency could be used to hide the compile time. Lars said the compiler did a single pass, so I can imagine V8 compiling a stream of source code as it arrives over the wire.
The memory requirements like you say must be large though, but I guess this is less of a concern today compared to when you guys where working on Strongtalk.
In short, it sounds like other dynamic languages, in addition to Javascript will be plenty fast enough on V8. Interesting times.
Thanks again to you both.
Paul.
Hi Paul,
re reification, exactly. Apart from concerns about security (for which Gilad proposes the use of mirrors to mediate access to stack frames) one could imagine an evolution of V8 supporting stack reification, but in the interim one could develop on a VM that supports reification and deploy through V8.
re single-pass compilers, it could be that V8 does compile an entire script at once. But it is doing substantial code generation at run-time. Remember Lars' description of class mutation for the Point constructor. The run-time generates (or at least installs) the accessors for the properties at run-time when the code is first run. Deferring things as late as possible often allows one to generate better code. There is a spectrum from interpreter, where all code has been generated before the program is run, to late-binding just-in-time compilers to tracing compilers and adaptive optimizers where code is generated just before, during and indeed after it is run. Code generation can occur afterwards e.g. when guards fail and the run-time must fix-up the code to deal with e.g. a new type at an old code site.
Interesting times indeed.
best
Eliot
Paul,
If you're interested in the workings of V8, you might enjoy Lars' interview with Erik Meijer:
http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine/
Doesn't Google's development of the Google Native Client offer language implementors an alternative assembly language to compile to, namely x86?
See:
http://en.wikipedia.org/wiki/Google_Native_Client
http://news.cnet.com/8301-17939_109-10251563-2.html
Rob,
x86 is indeed universal on the desktop - but Google Native is not at all. It's plugin under development. In time, if it works well, it may become ubiquitous in some form. Even then, x86 (or rather, the subset permitted by Google native) won't cover the mobile space.
Post a Comment