Comment by georgemcbay | Hacker News Reader

Comment by georgemcbay | Hacker News Reader

I feel for Brendan Eich, he is a bit of an unsung hero when you consider what he enabled with JavaScript and it is always stressful to learn someone is trying to kill your baby.

Having said that, I really do hope it is killed. Well, not killed, but demoted to "one supported language of many". And the sooner this is started, the better, because it is a long, long process. I don't think JavaScript is bad, but I do strongly feel that the underlying engine for client side web programming should be a full-blown VM that supports many possible source languages (ala modern .net with the CLR, DLR and all), and I'll support that model regardless of who pushes it, so long as they do a good job on the technical side and don't try to use it as a lock-in mechanism. Google seems to be the most posed to do this (I can't imagine Microsoft giving up that much control of .net) and their idea to support JavaScript as an interim target is the only practical way this will ever be solved, so I hope Dart is successful -- assuming it is actually going for this and not just trying to switch one core language out with another, which remains to be seen when they announce more information.

BTW, yes, I know you can already compile many other languages to JavaScript (as Dart itself will do in the first stage), but.. why? Why not just put a proper VM down there that is truly designed to efficiently run byte-code from many different source languages, and have JavaScript be one of those languages?

Brendan has previously talked about some obstacles to a bytecode/VM-level specification, and some advantages of specifying the browser language at the source level rather than at the bytecode level:

http://news.ycombinator.com/item?id=1893686 (see comments by BrendanEich and others)

http://www.aminutewithbrendan.com/pages/20101122

http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...

The main problem with common VMs for multiple existing languages is that often the semantics of the language are heavily coded into the VM. For example, Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!" There are a lot of other issues as well, and while they are certainly solvable, the resulting VM would be very heavyweight. If you want to design a VM that runs multiple languages, often you have to design the languages around the VM.

Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!"

That's true only for the intrinsic STRING type. Language-specific strings supply their own boolean semantics.

But then if the VM optimizes code paths related to STRING operations, languages can't take advantage of them as easily.

There's a reason why the fastest VMs are deeply tied to the semantics of the language they support, LuaJIT being the best example.

You're right about LuaJIT, but there's no reason the VM can't also optimize code paths related to high-level string operations.

Well, at some point you might run out of space in the opcode byte (or multiple bytes), and then you need longer sequences that put up more cache pressure and require more time decoding, right?

Also, the developers time budget and the VMs complexity migth keep you from optimizing all possible paths.

Google's PNaCl is trying to promote this. I've talked about this a few weeks ago[1]. But until it gets widely deployed and accepted, it is just yet another standard[2] that will unify everything.

[1] http://bit.ly/phxe16

[2] http://xkcd.com/927/

It's not even another standard - it's an experimental implementation.

A standard VM/Runtime specification for all the browser would be awesome. We got plenty of them; CLR, DLR, JVM, Parrot, etc. Can you imagine? I can see those mime types already: application/csharp, application/perl, application/ruby, application/IL.

To be pedantic, it wouldn't be "application/csharp". By the time it's compiled to MSIL bytecode it doesn't matter if it was C#, VB, F# or whatever. "application/MSIL" is what I'd say.

I can imagine it, and I guess my browsers already have three VM/Runtimes in them (JavaScript, Flash, Silverlight) but it feels so inelegantly top-heavy to have lots more.

Right, call me silly but I'm honoring the "Right-click->View Source" spirit here, I don't know about you but I feel more confortable knowing that my browser is downloading source code and compiling or interpreting than downloading some kind of binary to execute, even if you call it "intermediate code", "byte code" "almost-there-machine-code" or whatever, it's still binary stuff. I get your point though.

I agree, source is better.

But. Flash isn't served as source, is it? And JS is often minified/obfuscated. Sure you can run that through a tool to get back the source (sans comments and long variable names) but you can do just that with MSIL bytecode too.

Yep, Agree. Then we will see how additional tabs emerge in Firebug and Chrome Developer Tools, I can see them already: "IL View", ".NET Refactor", "JSIL View" hehe.

This was the original intent (to have many languages supported by browsers; not necessarily a single VM with many languages). It just never really materialized. By the time the web was ready for bigger apps that needed more software, Javascript was Good Enough for the purpose, and munging other languages into the browser was too much effort. JavaScript grew up alongside HTML and the DOM, making it uniquely qualified for building applications around HTML and the DOM. I think it's telling that Google is building a new language rather than modifying an existing one (though it does appear to be inspired by other languages).

I agree with your conclusions, especially that it's telling what Google is not doing, but I have to object to your "This was the original intent" lede. Whose intent was that? Not Sun's in '95 or '96 with the JVM, which was all about Java. Certainly not Netscape's.

Multi-VM/multi-language beats multi-language-single-VM, indeed, but then you have problems such as the cross-heap cycle collection one I raised on this thread. No free lunch.

And anyway multi-language-single-VM was never any browser vendor's original intent. I had folks like John Ousterhout belatedly (early '96) pitching TCL, but smart enough to see that it wouldn't fly (John then tried pitching Tk for cross-platform widgets, but Netscape was already screwing up its platform -- no sale).

Mid-90s C-Python, TCL, Perl 4 then 5 -- none of these was ever intended to be wedged into any browser and kept up-to-date. Not by Netscape or Microsoft or any vendor of that era, and not in the 2000s either. MS put IE on skeleton crew maintenance. The Silverlight-era "DLR" (single VM for many languages) was much later and not browser-bound.

"Whose intent was that?"

I have no idea. But, the script tag in HTML, for example, allows specification of language (i.e. "<script type="text/javascript">, historically). It was my understanding that this was intended to permit other languages to be included in the browser, or as plugins. It was used by Microsoft for vbscript, and others along the way. I thought that was the intent of that flexibility built into HTML.

And, I noted that it was not intended for a multi-language VM ("not necessarily a single VM with many languages", to quote myself, which I guess could have been more emphatic in denying that a multi-language VM was intended; I sort of assumed everyone would consider multi-language VMs the new hotness and not something that would have been considered back in the early days of VM-based languages becoming mainstream).

I merely meant that other languages were supposed to be possible. Which makes sense. No one knew (maybe you had a gut feeling), with any confidence that JavaScript would grow up to be as capable as it has. And, the idea of a multi-language multi-paradigm VM is pretty novel stuff even now. Only in the past ten years or so have we started to see people building disparate languages on a single VM and others building VMs for the purpose of hosting widely varying languages. And, those experiments are still up in the air, as far as I can tell. The JVM does pretty well for Java-like languages, and Parrot can run dynamic languages, and LLVM is great for C/C++ and their descendants...but, push them out of their comfort zone and things get hairier and the VM probably needs to grow bigger and more like the language it is hosting. They'll probably work it all out eventually. But, I certainly don't think multi-language VMs were on the minds of the creators of HTML or the browser makers.

I'm not sure we disagree (and I would obviously have to defer to your much greater knowledge on the subject, even if we did disagree). I could have been more clear in what I was suggesting was "the original intent".

I'm the guy that created <script> -- big dummy me first used language="JavaScript", not type= -- type came in HTML4 (where Dave Raggett invented "text/javascript", never registered; see RFC 4329).

Yes, I added language= at the start, but the default was JS and I had no particular intention to support other languages using one or more VMs. I see what you mean now, though -- thanks. Hope this history helps. It's less meaningfully intentional than you thought. More like blind future-proofing.

"More like blind future-proofing."

To me, through my own skewed historical lens, it looks like an admirable level of humility. So, good job.

While that flexibility was mostly used for evil, rather than good (vbscript, for instance), I think it probably helped build a stronger web ecosystem having competitors to the throne even if none ever really got a foothold against JavaScript.

The reason you won't see a bytecode VM replace Javascript is because bytecode is either interpreted (slow) or JIT-compiled (complicated but faster). If you go for speed and JIT-compile bytecode, why not just compile your source and dispense with bytecodes altogether (as V8 has done)? This gives other runtime implementers the freedom to choose whether to create an interpreter, compiler, or some other execution mechanism, and the programmers the freedom to code at a high-level.

Bytecode, as distinct from object code, is on the way out. Consider Javascript a portable high-level object code and move on. If you want other languages, compile them to Javascript. Semantic affinity between source language and execution environment (e.g. is "0" false, as mentioned elsewhere) is an issue you'll need to address regardless of whether you're using bytecode.

Also, don't underestimate the power 'view source' had in making Javascript perhaps one of the most widely-adopted programming languages in the world.

The trouble with this approach is that the Javascript prototype-based object model is somewhat incompatibile with precompiled-library loading. Loading Javascript (Even in bytecode form) requires running the code. Modern desktop/server software leverages tons of code via shared-libraries with fast startup times, but Javascript webpages have horrible startup times with only tiny amounts of library code. This problem is important to fix or the javascript ecosystem will be prevented from effectively building higher and higher leverage software layers.

In addition, Javascript's abstractions are based on relatively slow mechanisms such as dynamic-hashes. This make it difficult if not impossible to get C/Java/C# like performance out of it even with a JIT. You can build fast dynamic hashes out of structs, but you can't really build fast structs out of dynamic hashes.

Evaluating function declarations and expressions, even in a module pattern closure, takes well under a millisecond in modern browsers.

The "dynamic-hashes" remark shows serious ignorance of polymorphic inline caches and shapes aka hidden classes. Competitive JS JITs do not probe hashtables for dot member accesses.

Reply on news.ycombinator.com