3 ms·
JavaScript as a compilation target is ineffecient for both runtime and development; it's a hack. PNaCL -- and any other alternatives -- are in no small part in
by skatepark 14y ago
JavaScript as a compilation target is ineffecient for both runtime and development; it's a hack.
PNaCL -- and any other alternatives -- are in no small part incomplete because Eich has stated repeatedly in no uncertain terms that its JavaScript or nothing.
If you want to produce an alternative, there's no chance of it being accepted.
Imagine this sort of total language myopia in any other general purpose platform.
- BrendanEich 14y agoYup, I did it all -- mwah-hah-hah! I made Apple and Microsoft, iOS WebKit minions at Apple especially, even SJ, do my bidding in resisting poor pretty PNaCl. Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/ http://asmjs.org/. Cross-browser. /be
- skatepark 14y ago> Yup, I did it all -- mwah-hah-hah! I made Apple and Microsoft, iOS WebKit minions at Apple especially, even SJ, do my bidding in resisting poor pretty PNaCl. No, you've simply held back the only other entity interested in making the web a viable app platform: - MS and Apple, and Google's behavior are aligned with their corporate incentives. - In theory, Mozilla's behavior ought to be aligned with the interests of the web at large, but in practice, Mozilla is aligned with you, and your behavior is aligned with your own personal interest in a web platform monoculture based on your technology. Mozilla and Google, in concert, have the ability to make it a market necessity for Apple and Microsoft to follow suit. Google alone does not. This makes you the lynchpin at an organization that in theory was created for the very purpose of advancing the interests of the web. > Get your tums out, pal. We're taking PNaCl down for good this year with http://asmjs.org/ http://asmjs.org/. Cross-browser It takes a True Believer to abandon decades of research, ignore repeated market successes (in the application platform space) that vastly surpass anything they've produced, and then continue to myopically push their own invention into areas where it simply does not belong. The funny thing about asm.js is that it's an admission of the failings of standard JavaScript for this purpose, so much so that you have to define a strict subset, on top of which implementors will have to invest even more time and complex effort in providing quality implementations. This is death by a thousand cuts.
- callahad 14y ago> The funny thing about asm.js is that it's an admission of the failings of standard JavaScript for this purpose, so much so that you have to define a strict subset I'm surprised you find that approach controversial. Have you not seen the awesomesauce that Re2 and PyPy bring to the table by defining strict subsets of PCRE and Python, respectively?
- pcwalton 14y ago"on top of which implementors will have to invest even more time and complex effort in providing quality implementations." It is actually quite easy to implement asm.js; you just carve a "native mode" out of the VM infrastructure that already exists. Much easier than inventing a full-stack VM from scratch.
- skatepark 14y agoIt'd be even easier with a clean bytecode, and it wouldn't require nearly as much effort and round-about solutions. It also would simplify portable tool development, including source-level debuggers.
- tedmielczarek 14y agoAnd if we're living in a fantasy world, we can all get a pony, too. The fact remains that JavaScript is widely deployed and has multiple viable competing implementations. Any hypothetical bytecode format starts at a huge disadvantage due to this reality. The path of least resistance here is to target JavaScript.
- skatepark 14y agoThe "path of least resistance" has not been particularly successful in helping the web provide a robust platform for application development over the past 10 years. I don't see why the hack-and-slash "pragmatism" should be expected to start working now.
- Shorel 14y ago> JavaScript as a compilation target is ineffecient for both runtime and development; it's a hack. Honestly that's only an implementation dependent detail. If there is a fast compiled Lisp like SBCL, a fast JavaScript can certainly be done.
- skatepark 14y ago> Honestly that's only an implementation dependent detail. Not really, no. JavaScript is a ridiculously high-level target for another language, and this introduces a huge amount of complexity in any effort to target it efficiently. You can pare down JavaScript, as Eich seems to be banking on, but what possible technical reason is there for this? If what you care about is compatibility with Apple/MS browsers, then generate JavaScript from your intermediate bitcode/bytecode, and let those browsers be slow and complicated and have worse development tooling.
- pcwalton 14y ago"If what you care about is compatibility with Apple/MS browsers, then generate JavaScript from your intermediate bitcode/bytecode" Which is precisely what the Mozilla Emscripten project does.
- skatepark 14y agoEmscripten doesn't treat LLVM bitcode as a first-class target, it treats it as an intermediate target to be translated into JavaScript. [high level language] -> [low level representation] -> [high level language] -> [low level representation] -> [execution] This is ridiculous to aim for as your first-order target.
- bzbarsky 14y agoPNaCL is "incomplete" (as in, not working) because no one actually knows how to make it work, though they've been trying to figure it out for years. The fact that it's a hard problem has nothing to do with Brendan saying he doesn't like the idea.