5 ms·

First, you missed my point, which was clear enough from the context you cut: stagnation would have been a problem for any hypothetical Python circa version 1.3,

First, you missed my point, which was clear enough from the context you cut: stagnation would have been a problem for any hypothetical Python circa version 1.3, wedged into Netscape Navigator (other problems listed below). It would have been flash-frozen in 1995, not just due to standardization or Netscape losing the first browser war, simply due to the Web's scale. Python (like Lua, Perl, etc.) had to evolve backward-incompatibly, and thankfully could do so as a Unix-y and server-side command line. As a browser-embedded scripting engine, don't-break-the-web selection pressure would have forked and stunted early Python or any other language about as badly as JS, ignoring the spurious (to what I wrote) "Blub was a better language to start from" benefit. That's the main point. Python was never an option, anyway, as I've remarked in many places. Netscape management insisted on "make it look like Java", and time pressure combined with "don't be too big a sidekick" angst from Sun kept such things as classes out of JS in the early days (it took till ES6 to add classes). Python had OS-specific APIs and an unsafe FFI to boot, so would have been forked by stripping out many features, too. Fuzz testing would have exacted further costs, but I'll stop here. Python was never an option in the '90s, for many reasons. BTW, I did help manage and fund Mark Hammond (then at Active State), when I was leading Mozilla in the early noughties, to add C-Python as an alternative scripting language engine to Gecko. That code was for Active State's Komodo IDE, which used Python in XUL script elements. But the DOM complexity tax was bad enough that Gecko maintainers ripped it all out just a couple of years ago. See https://bugzilla.mozilla.org/buglist.cgi?order=Importance&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&classification=Client%20Software&query_format=advanced&component=PyXPCOM&product=Other%20Applications https://bugzilla.mozilla.org/buglist.cgi?order=Importance&re... So I know a lot more about what you're blithely talking about, from actual experience, than you do. Finally, your hyperbolic language ("tragedy") is off target. Mozilla is way underfunded compared to all of the other browser vendors. It could and still can least afford to jam in other languages, plus pay the requisite inter-heap cycle collector and write-barrier overhead costs you neglect to mention. Falling on this sword would have done nothing -- did nothing even with Mark Hammond's fine work -- to displace JS or get other browsers on board. It would have helped Mozilla fail, though. You'd do better to cry that Google did not fund, out of its massive profit margins and market cap, engineers to add such things to other open source engines -- as Microsoft has done with Pointer Events for Gecko and WebKit. Please do name a standard that Mozilla supports which is both (a) more complex than multiple language runtimes embedded and integrated with a low-overhead-enough inter-heap cycle collector; and (b) not already obligatory for competitive browsers to support (as Dart certainly is not!). Take your time; list your references. Apple and Microsoft won't fund such follies, and even Google has yet to ship Dart on top of Oilpan in Chrome (https://www.chromestatus.com/features/6682831673622528 https://www.chromestatus.com/features/6682831673622528). This is not a case of me as past Mozilla leader ducking "responsibility" to fund your pet follies based on breathtakingly incomplete HN-comment assertions about low complexity from you. I don't owe you or anyone that big a free lunch. (How about you write the patch and submit it, with tests, and then talk to Mozilla or any other open source browser project.) Rather, it's a set of three confirming signals showing that while talk is cheap, multiple independent language engines in one browser certainly are not. Only Google has the funds and engineers to burn on such speculative work. And it's an open question whether Chrome has the market power to make any such extension "stick" as a de-facto standard.

lmm 12y ago
> As a browser-embedded scripting engine, don't-break-the-web selection pressure would have forked and stunted early Python or any other language about as badly as JS, ignoring the spurious (to what I wrote) "Blub was a better language to start from" benefit. All (successful) languages ossify sooner or later - just look at how long promised Java improvements are taking to arrive. Python 3.4 is recognizably the same language as Python 1.3, and still suited for much the same problems; it's never going to be Perl or OCaml, even with that ability to make backwards-incompatible changes that JS doesn't have. Where you start from matters. > Netscape management insisted on "make it look like Java", and time pressure combined with "don't be too big a sidekick" angst from Sun kept such things as classes out of JS in the early days (it took till ES6 to add classes). Exactly! A language that was designed to not be a replacement for Java for serious, large-scale programming programming, turns out to... not be a replacement for Java for serious, large-scale programming, surprise. No-one is denying (I hope) that JS is a very good language within the constraints it was designed for. But today's use cases are very different from making the monkey dance; the things we're writing in JS today are much closer to the things we were writing in Java 10 years ago than they are to the things we were writing in JS 10 years ago. JS's unsuitability for certain problems is a result of design decisions, not any "stagnation"; no amount of active development (as welcome as it is) is going to make language X into language Y, and no language can be all things to all people. With the browser becoming more and more of an OS, requiring all web programs to be written in the same language is as wrong as requiring all non-web programs to be written in the same language. > How about you write the patch and submit it, with tests, and then talk to Mozilla or any other open source browser project. Wait, Mozilla would accept my patches? Of course Mozilla should allocate their own engineering effort as they see fit (we may disagree about specifics). But my understanding, and the part I took issue with, was that Mozilla was refusing to ever embed Dart as a matter of policy.
- BrendanEich 12y ago
  You're still changing the subject, and now moving the goal posts. I didn't have Python 3.4, or 2.5, to start from in 1995. I had 1.3, and it wasn't possible for other reasons. Are you really arguing that, in the far-away-in-the-multiverse world where it didn't have to look like Java, I had time to make a safe, FFI-free subset, etc. etc., Python 1.3 in Netscape 2 would have evolved any faster than JS did? ES1: 1997 ES2, just the ISO version of ES1, pro-forma changes: 1998 ES3: 1999 ES4: mothballed in 2008 ES5: 2009 We had to restart browser competition with Firefox even to get a crack at updating ES3. Competition drives standardization; the IE monopoly stagnation mattered. Most of the rest of your post is flogging "Blub is better". No one agrees on Blub, and there's no way to replace JS with it. Meanwhile, JS is evolving, not just ES6 but ES7/2016 and beyond. Betting against evolution on the Web is risky, in my view. I don't think you're being serious about the work to develop a multi-language-runtime embedding framework. It would not be one patch. You'd have to solve the write barrier cost implied by cycle collection among heaps (see Filip Pizlo of Apple on webkit-dev, I cited this already): https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... I never refused "as a matter of policy" to embed Dart. Excuses for not working on the real and complex problems with multi-language-runtime VMs are one thing -- making stuff up is another.

lmm 12y ago

> As a browser-embedded scripting engine, don't-break-the-web selection pressure would have forked and stunted early Python or any other language about as badly as JS, ignoring the spurious (to what I wrote) "Blub was a better language to start from" benefit. All (successful) languages ossify sooner or later - just look at how long promised Java improvements are taking to arrive. Python 3.4 is recognizably the same language as Python 1.3, and still suited for much the same problems; it's never going to be Perl or OCaml, even with that ability to make backwards-incompatible changes that JS doesn't have. Where you start from matters. > Netscape management insisted on "make it look like Java", and time pressure combined with "don't be too big a sidekick" angst from Sun kept such things as classes out of JS in the early days (it took till ES6 to add classes). Exactly! A language that was designed to not be a replacement for Java for serious, large-scale programming programming, turns out to... not be a replacement for Java for serious, large-scale programming, surprise. No-one is denying (I hope) that JS is a very good language within the constraints it was designed for. But today's use cases are very different from making the monkey dance; the things we're writing in JS today are much closer to the things we were writing in Java 10 years ago than they are to the things we were writing in JS 10 years ago. JS's unsuitability for certain problems is a result of design decisions, not any "stagnation"; no amount of active development (as welcome as it is) is going to make language X into language Y, and no language can be all things to all people. With the browser becoming more and more of an OS, requiring all web programs to be written in the same language is as wrong as requiring all non-web programs to be written in the same language. > How about you write the patch and submit it, with tests, and then talk to Mozilla or any other open source browser project. Wait, Mozilla would accept my patches? Of course Mozilla should allocate their own engineering effort as they see fit (we may disagree about specifics). But my understanding, and the part I took issue with, was that Mozilla was refusing to ever embed Dart as a matter of policy.

BrendanEich 12y ago
You're still changing the subject, and now moving the goal posts. I didn't have Python 3.4, or 2.5, to start from in 1995. I had 1.3, and it wasn't possible for other reasons. Are you really arguing that, in the far-away-in-the-multiverse world where it didn't have to look like Java, I had time to make a safe, FFI-free subset, etc. etc., Python 1.3 in Netscape 2 would have evolved any faster than JS did? ES1: 1997 ES2, just the ISO version of ES1, pro-forma changes: 1998 ES3: 1999 ES4: mothballed in 2008 ES5: 2009 We had to restart browser competition with Firefox even to get a crack at updating ES3. Competition drives standardization; the IE monopoly stagnation mattered. Most of the rest of your post is flogging "Blub is better". No one agrees on Blub, and there's no way to replace JS with it. Meanwhile, JS is evolving, not just ES6 but ES7/2016 and beyond. Betting against evolution on the Web is risky, in my view. I don't think you're being serious about the work to develop a multi-language-runtime embedding framework. It would not be one patch. You'd have to solve the write barrier cost implied by cycle collection among heaps (see Filip Pizlo of Apple on webkit-dev, I cited this already): https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... I never refused "as a matter of policy" to embed Dart. Excuses for not working on the real and complex problems with multi-language-runtime VMs are one thing -- making stuff up is another.