28 ms·

Do a search for BrendanEich on hnsearch.com, he's discussed it many times. I'm curious why you're asking about Mozilla and not Apple or Microsoft, though, they

Do a search for BrendanEich on hnsearch.com, he's discussed it many times. I'm curious why you're asking about Mozilla and not Apple or Microsoft, though, they aren't implementing NaCL either.

dman 14y ago
One reason could be that there are higher expectations of Mozilla when it comes to making decisions on technical merit.
- BrendanEich 14y ago
  No one has made the case that PNaCl/Pepper has more technical merit than Emscripten(or Mandreel, e.g.) / asm.js / WebAPIs. Assuming is a mistake. /be
  - chadaustin 14y ago
    It's of course risky to discuss something that hasn't shipped, though extrapolating PNaCl's behavior from its architecture isn't that hard. (It's just NaCl except that LLVM is compiled to NaCl on load. And LLVM itself runs within the NaCl sandbox too.) Off the top of my head, if PNaCl existed today, its advantages would be: access to SIMD units, true threads, 64-bit integer operations, 32-bit floats, debuggability with nacl-gdb, a growable heap, support for exceptions/setjmp, and no ridiculousness like: https://mail.mozilla.org/pipermail/es-discuss/2013-March/029519.html https://mail.mozilla.org/pipermail/es-discuss/2013-March/029... As a browser implementer, you are fully justified in rejecting Pepper. :) Permanent APIs should go through some kind of standardization process. (Or they should HAVE, cough XHR) I gave a presentation at GDC this morning* on Emscripten and asm.js and agree that asm.js has better survivability characteristics and is likely to succeed in the market. Nonetheless, the proposed design of PNaCl has several technical merits over asm.js as it exists today. In the meantime, please add 64-bit integers, threads, and SIMD to asm.js :) * It occupied the same time slot as the Mozilla presentation! arg! Edit: forgot exceptions, setjmp, and a growable heap, none of which work in asm.js today. I know, I know, asm.js is early, but the point I'm making is that we're comparing two theoretical technologies at this point.
    - kevingadd 14y ago
      I believe 64-bit integers are in the works already. https://bugzilla.mozilla.org/show_bug.cgi?id=749786 https://bugzilla.mozilla.org/show_bug.cgi?id=749786
      - chadaustin 14y ago
        Right, but until they're in the language spec and implemented across browsers, you can't use 64-bit integer value objects in asm.js code unless you can polyfill or generate asm.js code that only runs in the latest Mozilla or whatever.
        BrendanEich 14y ago
        So? You can't use PNaCl at all yet, and you can use NaCl only in Chrome and only loading content from the CWS. Please use the same yardstick! The cross-browser evolving standards story is the winner, not only long-term but shorter term. There is no serious argument to the contrary. /be
        NinjaWarrior 14y ago
        How about evaluating both (asm.js and PNaCl)? Looks like we are stuck in the "monoculture" you said you dislike. And this IS the reason I never love web standards. I don't like monocultures too. I feel you are biased to preserve JavaScript because you are the creator of JavaScript. IMO, asm.js might beat Flash but has a clear dead-end to beat native. We all are in a local optimum trap, I think.
        BrendanEich 14y ago
        Do we all buy two significantly different and expensive cars to "evaluate" both? Most people can't afford to do any such thing. Nor do we all buy the same make and model of car. That's implementation monoculture. Monoculture of implementation (WebKit, which I pointed out is fragmented in practice) is not the same as a single vocabulary for each kind of language at the primitive level of the web standards layer cake. Yes, we are stuck with the web platform bottoming out at a certain set of languages. That's not monoculture, rather: termination without too much redundancy in something not so complex that multiple browsers can hope to implement interoperably. The platform has to stand on certain primitives. Remember XHTML2 vs. HTML5 back in 2005? It was going to be one or the other, even if browsers such as Firefox parsed both (but XHTML2 slowly and without incremental layout). Maybe a Microsoft or Google could have "done both" well (but IE didn't, except by treating text/xhtml as error-corrected HTML!). Without a single dominant browser vendor with enough cash and willpower to pull off more than the minimum set of semantically sufficient/complementary primitive languages, we were likely stuck with HTML/CSS/JS. SVG and MathML as HTML5 polyglot languages eventually were rationalized into the stack but still see too little use to be optimized well (and didn't Chrome turn off MathML recently?). So the primitives have to be minimized against competing browsers' ability to implement them all interoperably. Browsers weren't going to do equally well at both the 2005-era XML languages (XHTML/SVG/XSLT) and the competing incremental plan (HTML5). Arbitrary native code has been falling out as a part of the primitive layer for a while. Plugins such as Flash and Silverlight are in decline. You could say we had a plugin polyculture, but it was a security nightmare and also bad for users just in terms of updates and cross-browser/plugin UX consistency. Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow. Consider also how Dart support (2nd VM, in particular GC barriers required for cross-VM-heap cycle collection) bounced off WebKit: https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... I'm mostly being descriptive so far, but let me prescribe: Based on the hard multi-vendor specification and software engineering problems of doing well with a roughly minimized set of primitives that we have today, I do not believe it's "better" for anyone, especially for web developers, to over-extend the primitive set with things like NaCl and Pepper. That applies even if one vendor could, e.g., add SIMD primitives quickly. That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS. Same goes for Dart. It was so important to do as a "replacement" (see leaked Dash memo) and not wait for the standards bodies, but that started in 2010 (or earlier? I knew only for certain in spring 2010). It's 2013 now and Dart is not going cross browser. Things it wanted, e.g. bignums, could have been put in ES6 by now and implemented in leading JS engines. I do not agree we are in a local optimum trap, not with Unreal 3 running within 2x of native unsafe code speed. /be

Do a search for BrendanEich on hnsearch.com, he's discussed it many times. I'm curious why you're asking about Mozilla and not Apple or Microsoft, though, they aren't implementing NaCL either.

dman 14y ago

One reason could be that there are higher expectations of Mozilla when it comes to making decisions on technical merit.

BrendanEich 14y ago
No one has made the case that PNaCl/Pepper has more technical merit than Emscripten(or Mandreel, e.g.) / asm.js / WebAPIs. Assuming is a mistake. /be
- chadaustin 14y ago
  It's of course risky to discuss something that hasn't shipped, though extrapolating PNaCl's behavior from its architecture isn't that hard. (It's just NaCl except that LLVM is compiled to NaCl on load. And LLVM itself runs within the NaCl sandbox too.) Off the top of my head, if PNaCl existed today, its advantages would be: access to SIMD units, true threads, 64-bit integer operations, 32-bit floats, debuggability with nacl-gdb, a growable heap, support for exceptions/setjmp, and no ridiculousness like: https://mail.mozilla.org/pipermail/es-discuss/2013-March/029519.html https://mail.mozilla.org/pipermail/es-discuss/2013-March/029... As a browser implementer, you are fully justified in rejecting Pepper. :) Permanent APIs should go through some kind of standardization process. (Or they should HAVE, cough XHR) I gave a presentation at GDC this morning* on Emscripten and asm.js and agree that asm.js has better survivability characteristics and is likely to succeed in the market. Nonetheless, the proposed design of PNaCl has several technical merits over asm.js as it exists today. In the meantime, please add 64-bit integers, threads, and SIMD to asm.js :) * It occupied the same time slot as the Mozilla presentation! arg! Edit: forgot exceptions, setjmp, and a growable heap, none of which work in asm.js today. I know, I know, asm.js is early, but the point I'm making is that we're comparing two theoretical technologies at this point.
  - kevingadd 14y ago
    I believe 64-bit integers are in the works already. https://bugzilla.mozilla.org/show_bug.cgi?id=749786 https://bugzilla.mozilla.org/show_bug.cgi?id=749786
    - chadaustin 14y ago
      Right, but until they're in the language spec and implemented across browsers, you can't use 64-bit integer value objects in asm.js code unless you can polyfill or generate asm.js code that only runs in the latest Mozilla or whatever.
      - BrendanEich 14y ago
        So? You can't use PNaCl at all yet, and you can use NaCl only in Chrome and only loading content from the CWS. Please use the same yardstick! The cross-browser evolving standards story is the winner, not only long-term but shorter term. There is no serious argument to the contrary. /be
        NinjaWarrior 14y ago
        How about evaluating both (asm.js and PNaCl)? Looks like we are stuck in the "monoculture" you said you dislike. And this IS the reason I never love web standards. I don't like monocultures too. I feel you are biased to preserve JavaScript because you are the creator of JavaScript. IMO, asm.js might beat Flash but has a clear dead-end to beat native. We all are in a local optimum trap, I think.
        BrendanEich 14y ago
        Do we all buy two significantly different and expensive cars to "evaluate" both? Most people can't afford to do any such thing. Nor do we all buy the same make and model of car. That's implementation monoculture. Monoculture of implementation (WebKit, which I pointed out is fragmented in practice) is not the same as a single vocabulary for each kind of language at the primitive level of the web standards layer cake. Yes, we are stuck with the web platform bottoming out at a certain set of languages. That's not monoculture, rather: termination without too much redundancy in something not so complex that multiple browsers can hope to implement interoperably. The platform has to stand on certain primitives. Remember XHTML2 vs. HTML5 back in 2005? It was going to be one or the other, even if browsers such as Firefox parsed both (but XHTML2 slowly and without incremental layout). Maybe a Microsoft or Google could have "done both" well (but IE didn't, except by treating text/xhtml as error-corrected HTML!). Without a single dominant browser vendor with enough cash and willpower to pull off more than the minimum set of semantically sufficient/complementary primitive languages, we were likely stuck with HTML/CSS/JS. SVG and MathML as HTML5 polyglot languages eventually were rationalized into the stack but still see too little use to be optimized well (and didn't Chrome turn off MathML recently?). So the primitives have to be minimized against competing browsers' ability to implement them all interoperably. Browsers weren't going to do equally well at both the 2005-era XML languages (XHTML/SVG/XSLT) and the competing incremental plan (HTML5). Arbitrary native code has been falling out as a part of the primitive layer for a while. Plugins such as Flash and Silverlight are in decline. You could say we had a plugin polyculture, but it was a security nightmare and also bad for users just in terms of updates and cross-browser/plugin UX consistency. Pepper is an attempt to mediate plugins' access to OS and browser APIs, but too tied to chromium and too large for Google to standardize or for other vendors to swallow. Consider also how Dart support (2nd VM, in particular GC barriers required for cross-VM-heap cycle collection) bounced off WebKit: https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... I'm mostly being descriptive so far, but let me prescribe: Based on the hard multi-vendor specification and software engineering problems of doing well with a roughly minimized set of primitives that we have today, I do not believe it's "better" for anyone, especially for web developers, to over-extend the primitive set with things like NaCl and Pepper. That applies even if one vendor could, e.g., add SIMD primitives quickly. That just fragments the picture for developers, and misdirects some energy that could be spent on adding SIMD to JS. Same goes for Dart. It was so important to do as a "replacement" (see leaked Dash memo) and not wait for the standards bodies, but that started in 2010 (or earlier? I knew only for certain in spring 2010). It's 2013 now and Dart is not going cross browser. Things it wanted, e.g. bignums, could have been put in ES6 by now and implemented in leading JS engines. I do not agree we are in a local optimum trap, not with Unreal 3 running within 2x of native unsafe code speed. /be