Hacker News new | comments | show | ask | jobs | submit login

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact