18 ms·

It's funny that time and time again MIT approach over Hacker approach fails. Worse is better so to say ;) On a simply theoretical ground having LLVM in browser

by Ygg2 13y ago

It's funny that time and time again MIT approach over Hacker approach fails. Worse is better so to say ;) On a simply theoretical ground having LLVM in browser sounds like an amazing thing. It elegantly solves all the problems of using different languages in browser, having super optimization of native LLVM project, etc. Then you look at Javascript. It was written in a week. It's a sloppy mess of Java, Self and Scheme merged into a single horrible entity. But It just works™. And now it works fast :D Good job Mozilla.

Refefer 13y ago
Let's make no mistake about it: Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. It's more accurate to say that Javascript has succeeded despite its limitations. There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. That said, a well entrenched language supported (and, crucially, maintained) by multiple vendors with loads of developer intellectual investment should win this competition.
- natural219 13y ago
  I think that's the thesis of the "worse is better" approach. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
- azakai 13y ago
  > There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. Not necessarily. That has been discussed at length many times here and elsewhere. PNaCl's approach is interesting and technically has much merit, but also has significant downsides (startup speed, complexity, size of implementation, reliance on LLVM for something it was not intended, risks of undefined behavior, PPAPI, etc.). It's technically an impressive technology but also one with fundamental compromises. Instead, an undeniably superior approach could be to start entirely from scratch, not JS nor LLVM nor anything else, and work to design something truly optimal for the use case we are talking about here (code shipped over the network, to run securely inside a browser, at near-native performance, with fast warm and cold startup). That would look very different from both JS and PNaCl, and could avoid the compromises that both have.
  - Refefer 13y ago
    Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point. I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.
    - azakai 13y ago
      > However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
    - BrendanEich 13y ago
      Java has a bytecode for its client embedding; so does Flash ActionScript. This led to trouble. From http://brendaneich.github.io/Strange-Loop-2012/#/27 http://brendaneich.github.io/Strange-Loop-2012/#/27, some pros for JS and cons for bytecode: * Dynamic typing ⇒ no verification * Type inference ⇒ delayed optimization * Would bytecode compress as well? * Bytecode standardization would suck * Bytecode versioning would suck more * Low-level bytecode is future-hostile Remember Java bytecode backward compatibility hampering language evolution, in the generics (erasure) debate and result. Then they broke bytecode compat anyway. Flash has two language implementations in it, one for AS2 and the other (Tamarin) for AS3. Only way to be sure about AS2 compat! In many ways, with JS you have one problem; add bytecode and now you have two.
- Ygg2 13y ago
  That's kinda my point as well. If we are to wipe clean. Nothing in browser for scripting exists. Some kid from Zambia develops JavScript 2.0 in two weeks. Entire Google team works out a specification for LLWM (Low Level Web Machine) and it's pretty close to LLVM. They take how long to implement it?! People need to get their browser scripted so they look around shopping for a new language. Oh, cool the awesome LLWM spec is out there. Wow. It's got all the thing they want. Let's wait.... A month passes. People look again but no LLWM. On the other hand there is this JavScript 2.0 that kind of works. It's ugly, but Mark took a look at it and he uses to make dancing kittens. In 3D (i.e. the picture just rotates around axis, using CSS). Another month passes. Is LLWM done yet? Hmm, the clients are itchy, they want their browser scripted. Maybe dabbling in that JavScript 2.0 doesn't sound so bad. Third month passes. LLWM is still being worked on. Your clients have employed Mark and dumped you. Yeah, life is cruel and JavScript 2.0 is more cruel - Integers overflow when adding two numbers with more than six digits each, it confuses 0 and o, no local variables, just global vars. ... Fourth month passes. LLWM is still being worked on. JavScript 2.0 sucks but everyone tolerates it. Also there is JavScript 2.1 comming out that allows variables to not be in UPPERCASE. And there is a nice library for dancing kittens called dance.jv2 ... Year passes. LLWM ships. JavScript 2.123 is out and it's about the same in terms of speed and features. Sure there are few warts here and there, like lack of static typing, but overall it's quite solid. Compare this situation with many other examples of Worse is Better.
  - cromwellian 13y ago
    How long between Javascript's "it only took 2 weeks" until now though? Is this is an example of "worse is better" innovating at faster speed, when in fact, Javascript performance has moved at a glacial pace until recently and it took enormous investment to get there. I think it is fair to say that if someone started with today's web/mobile requirements and designed a language from scratch to meet performance, latency, and memory requirements as well as portability/cross platform execution, it probably would not take as long as Javascript did to reach the current levels of performance. That is, you're comparing 15+ years of Javascript JIT engineering activity with what, 2-3 years of PNaCL activity by a much smaller team?
    - 13y ago
- BrendanEich 13y ago
  > Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. No, that's an exaggeration in time and dollars. JS was one full-time person, me, till fall 1996, then two. Growth after that was to about eight max, and less than the Java crew at Netscape, until Netscape folded on Java and laid off a bunch of people in late 1997. Call the Netscape investment 8 years x 8 people = 64. On the IE side, the JScript engine reused a common assembly-coded COM-dispatching indirect-threaded (I think) interpreter, and seemed from what I could tell to take about 6 people, but I'll round up to 8. No LiveConnect and COM based infrastructure saved them compared to Netscape. Ignoring JScript.net in Y2K era, the investment until the IE6 stagnation (skeleton crew) looks like at most 6 x 8 = 48. Apple did not start with KJS till 2001, I believe. They've always had at most 3 people on JavaScriptCore, they run a tight ship: 14 x 3 = 42. Chrome started V8 in 2006, as far as I can tell. Lars and a team of U. Aarhus and Google on his farm wrote four versions I hear (good idea: prototype, learn, tear up and rewrite). Call that 2 x 10 = 20 for first two years, then since I think it is more like 5 x 20 = 100. 64 + 48 + 42 + 120 = 274 person-years. Even at $1M/person/year, well high even with Google wealth effect of RSUs (for most; I'm guessing, but an outlier like Lars or Kaspar getting rich does not count; really we should stick to base salary + benefits/burden overhead), that's well shy of "multi-billion". You can say JS learned from all the JIT research before it. You'd be right, but your statement was exclusive to JS and so excluded that upstream, and fair's fair: that helped other languages who could read the literature and code. EDIT: Eric Lawrence on twitter reminds me that Chakra has a big team, I hear ~60 heads. That seems to be since 2009. Still well south of "multi-billion", even with my absurdly high $1M/year burdened engineer price. /be
  - magicalist 13y ago
    It's pretty interesting to see it laid out there in person years. It really is a small number (especially compared to the much larger number of bodies working on other parts of those browsers). I'll still take umbrage with the "MIT approach over Hacker approach" comment by the OP. "Worse is better" is fairly independent of that, and I think it does do disservice not only to the academic shoulders that the modern JS engines stand on, but also the academic brains packed into most of the JS engine teams (even just starting with the backgrounds of the editors of the asm.js spec). It's also amusing, of course, that the submitter of this article is bzbarsky, who has done amazing work for the web and whose mailing list correspondence, at least, all comes from an address ending with "@mit.edu" :)
jokoon 13y ago
I'd say that there is not any relevant business model that could bring developers to do impressive work and easily reach their audience. That's how hackers can win in the end. Business models get the market stuck somewhere, but you can't prevent hackers to find a difficult, hard path to reach their goals. ASM.js is an impressive tech yes, but as always, I'm curious if it can really attract more devs into releasing gaming software. The real advantages of ASM.js is security and the non requirement to install something new like NaCL.
- _random_ 13y ago
  "The real advantages of ASM.js is security" - isn't NaCl sand-boxed?
  - jokoon 13y ago
    I'm not sure but I think it's not a real sandbox, the code is still executed like any native code, the code is just thoroughly checked for instructions that would try to access things that are not supposed to be accessed. It's just some kind of compiling that does very strict security checks, and maybe recheck the executable file hash to match. NaCL is at true native speed, but the fact that it's still a "beta product" shows that it's not 100% safe. Well anything really is 100% safe, but if NaCL isn't entirely safe, a NaCL vulnerability could be quite disastrous. That's where the google beta culture lag behind. Security is still the most important features of any massively distributed product. If ASM.js manages to reach a mere 2x slowdown, it's great because it does in the context of an interpreted, thoroughly tested JS engine, which is very much more secure. NaCL introduces new standards and compiling methods, which would require a lot of testing and reviewing before being really deemed secure. There are a balance of pro and cons, but in the grand battle of big innovations, keeping things secure is a hard problem, because you can't always introduce new things without creating new risks. asm.js relies heavily on the fact that it uses an old, crap language, but since JS engines are heavily optimized, it makes the security problem disappear completely because JS is an old language, so all security problems are already known. It's a problem about how developers practice their job, what they use, how it is deployed and ran by users. Innovation on a massive scale and security never mix well. Also, execution speed and security don't mix very well. The fact android uses java for its app is another demonstration of the easiest path to security.
jlebar 13y ago
Not to pick nits -- it's not the thrust of your argument -- but web browsers have a complex relationship with worse is better today. Yes, browsers started as a hack and it's reasonable to attribute a lot of their success to worse is better "survival characteristics". But having been in the trenches for a few years, I can say that these days, we operate primarily on the MIT approach. For example, WebSQL is worse-is-better; it was rejected in favor of IndexedDB, which is the "right way" (and was a ton more work). At least at Mozilla we were /obsessed/ with making the "right" api; a hack that we felt placed burden on users, like Unix's solution to the lusering problem, would be seriously looked down upon. Indeed I'd argue that the fact that so much work happens in standards bodies may be browsers' biggest concession to the "right way". There are, of course, plenty of modern counterexamples to this too. Like I say, it's a complex relationship...
- Ygg2 13y ago
  True. I'm not making it look like Worse is Better ALWAYS wins. But it is funny how often it does, contrary to common conceptions. The 'fight' between (P)NaCl and asm.js is by no means over. It's hasn't even begun. I have no clue if NaCl is popular for games, I've saw some on Chrome Store, but they always felt weird. I just like to remind myself that making something is often more important than making it right.
lmm 13y ago
I don't see this as good job Mozilla; I see this as Mozilla using their muscle to keep everyone stuck on Javascript. If Mozilla had been willing to adopt the elegant approach then it would have succeeded. This is a triumph of politics, not of hacking - or to be more charitable, of hacking around politically-imposed constraints rather than fixing them.
- BrendanEich 13y ago
  From my throne of skulls (https://t.co/CJUs7E3x43 https://t.co/CJUs7E3x43), I'm flexing and posing. Muscle, that's a laugh! Who is the big company with all the money in the world to throw at developers and publishers to use a plugin API supported only in their browser, and still the devs and pubs say no? We heard from another such developer just this week. s/politically-imposed/physics-imposed/ -- fixed it for you.

by Ygg2 13y ago

Refefer 13y ago

Let's make no mistake about it: Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. It's more accurate to say that Javascript has succeeded despite its limitations. There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. That said, a well entrenched language supported (and, crucially, maintained) by multiple vendors with loads of developer intellectual investment should win this competition.

natural219 13y ago
I think that's the thesis of the "worse is better" approach. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
azakai 13y ago
> There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. Not necessarily. That has been discussed at length many times here and elsewhere. PNaCl's approach is interesting and technically has much merit, but also has significant downsides (startup speed, complexity, size of implementation, reliance on LLVM for something it was not intended, risks of undefined behavior, PPAPI, etc.). It's technically an impressive technology but also one with fundamental compromises. Instead, an undeniably superior approach could be to start entirely from scratch, not JS nor LLVM nor anything else, and work to design something truly optimal for the use case we are talking about here (code shipped over the network, to run securely inside a browser, at near-native performance, with fast warm and cold startup). That would look very different from both JS and PNaCl, and could avoid the compromises that both have.
- Refefer 13y ago
  Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point. I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.
  - azakai 13y ago
    > However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo. Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages. Worth reading this about the limitations of LLVM IR as a bytecode: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437... I've also written a post about the limitations of any single bytecode to achieve all the goals the web needs: http://mozakai.blogspot.com/2013/05/the-elusive-universal-web-bytecode.html http://mozakai.blogspot.com/2013/05/the-elusive-universal-we...
  - BrendanEich 13y ago
    Java has a bytecode for its client embedding; so does Flash ActionScript. This led to trouble. From http://brendaneich.github.io/Strange-Loop-2012/#/27 http://brendaneich.github.io/Strange-Loop-2012/#/27, some pros for JS and cons for bytecode: * Dynamic typing ⇒ no verification * Type inference ⇒ delayed optimization * Would bytecode compress as well? * Bytecode standardization would suck * Bytecode versioning would suck more * Low-level bytecode is future-hostile Remember Java bytecode backward compatibility hampering language evolution, in the generics (erasure) debate and result. Then they broke bytecode compat anyway. Flash has two language implementations in it, one for AS2 and the other (Tamarin) for AS3. Only way to be sure about AS2 compat! In many ways, with JS you have one problem; add bytecode and now you have two.
Ygg2 13y ago
That's kinda my point as well. If we are to wipe clean. Nothing in browser for scripting exists. Some kid from Zambia develops JavScript 2.0 in two weeks. Entire Google team works out a specification for LLWM (Low Level Web Machine) and it's pretty close to LLVM. They take how long to implement it?! People need to get their browser scripted so they look around shopping for a new language. Oh, cool the awesome LLWM spec is out there. Wow. It's got all the thing they want. Let's wait.... A month passes. People look again but no LLWM. On the other hand there is this JavScript 2.0 that kind of works. It's ugly, but Mark took a look at it and he uses to make dancing kittens. In 3D (i.e. the picture just rotates around axis, using CSS). Another month passes. Is LLWM done yet? Hmm, the clients are itchy, they want their browser scripted. Maybe dabbling in that JavScript 2.0 doesn't sound so bad. Third month passes. LLWM is still being worked on. Your clients have employed Mark and dumped you. Yeah, life is cruel and JavScript 2.0 is more cruel - Integers overflow when adding two numbers with more than six digits each, it confuses 0 and o, no local variables, just global vars. ... Fourth month passes. LLWM is still being worked on. JavScript 2.0 sucks but everyone tolerates it. Also there is JavScript 2.1 comming out that allows variables to not be in UPPERCASE. And there is a nice library for dancing kittens called dance.jv2 ... Year passes. LLWM ships. JavScript 2.123 is out and it's about the same in terms of speed and features. Sure there are few warts here and there, like lack of static typing, but overall it's quite solid. Compare this situation with many other examples of Worse is Better.
- cromwellian 13y ago
  How long between Javascript's "it only took 2 weeks" until now though? Is this is an example of "worse is better" innovating at faster speed, when in fact, Javascript performance has moved at a glacial pace until recently and it took enormous investment to get there. I think it is fair to say that if someone started with today's web/mobile requirements and designed a language from scratch to meet performance, latency, and memory requirements as well as portability/cross platform execution, it probably would not take as long as Javascript did to reach the current levels of performance. That is, you're comparing 15+ years of Javascript JIT engineering activity with what, 2-3 years of PNaCL activity by a much smaller team?
  - 13y ago
BrendanEich 13y ago
> Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. No, that's an exaggeration in time and dollars. JS was one full-time person, me, till fall 1996, then two. Growth after that was to about eight max, and less than the Java crew at Netscape, until Netscape folded on Java and laid off a bunch of people in late 1997. Call the Netscape investment 8 years x 8 people = 64. On the IE side, the JScript engine reused a common assembly-coded COM-dispatching indirect-threaded (I think) interpreter, and seemed from what I could tell to take about 6 people, but I'll round up to 8. No LiveConnect and COM based infrastructure saved them compared to Netscape. Ignoring JScript.net in Y2K era, the investment until the IE6 stagnation (skeleton crew) looks like at most 6 x 8 = 48. Apple did not start with KJS till 2001, I believe. They've always had at most 3 people on JavaScriptCore, they run a tight ship: 14 x 3 = 42. Chrome started V8 in 2006, as far as I can tell. Lars and a team of U. Aarhus and Google on his farm wrote four versions I hear (good idea: prototype, learn, tear up and rewrite). Call that 2 x 10 = 20 for first two years, then since I think it is more like 5 x 20 = 100. 64 + 48 + 42 + 120 = 274 person-years. Even at $1M/person/year, well high even with Google wealth effect of RSUs (for most; I'm guessing, but an outlier like Lars or Kaspar getting rich does not count; really we should stick to base salary + benefits/burden overhead), that's well shy of "multi-billion". You can say JS learned from all the JIT research before it. You'd be right, but your statement was exclusive to JS and so excluded that upstream, and fair's fair: that helped other languages who could read the literature and code. EDIT: Eric Lawrence on twitter reminds me that Chakra has a big team, I hear ~60 heads. That seems to be since 2009. Still well south of "multi-billion", even with my absurdly high $1M/year burdened engineer price. /be
- magicalist 13y ago
  It's pretty interesting to see it laid out there in person years. It really is a small number (especially compared to the much larger number of bodies working on other parts of those browsers). I'll still take umbrage with the "MIT approach over Hacker approach" comment by the OP. "Worse is better" is fairly independent of that, and I think it does do disservice not only to the academic shoulders that the modern JS engines stand on, but also the academic brains packed into most of the JS engine teams (even just starting with the backgrounds of the editors of the asm.js spec). It's also amusing, of course, that the submitter of this article is bzbarsky, who has done amazing work for the web and whose mailing list correspondence, at least, all comes from an address ending with "@mit.edu" :)

jokoon 13y ago

I'd say that there is not any relevant business model that could bring developers to do impressive work and easily reach their audience. That's how hackers can win in the end. Business models get the market stuck somewhere, but you can't prevent hackers to find a difficult, hard path to reach their goals. ASM.js is an impressive tech yes, but as always, I'm curious if it can really attract more devs into releasing gaming software. The real advantages of ASM.js is security and the non requirement to install something new like NaCL.

_random_ 13y ago
"The real advantages of ASM.js is security" - isn't NaCl sand-boxed?
- jokoon 13y ago
  I'm not sure but I think it's not a real sandbox, the code is still executed like any native code, the code is just thoroughly checked for instructions that would try to access things that are not supposed to be accessed. It's just some kind of compiling that does very strict security checks, and maybe recheck the executable file hash to match. NaCL is at true native speed, but the fact that it's still a "beta product" shows that it's not 100% safe. Well anything really is 100% safe, but if NaCL isn't entirely safe, a NaCL vulnerability could be quite disastrous. That's where the google beta culture lag behind. Security is still the most important features of any massively distributed product. If ASM.js manages to reach a mere 2x slowdown, it's great because it does in the context of an interpreted, thoroughly tested JS engine, which is very much more secure. NaCL introduces new standards and compiling methods, which would require a lot of testing and reviewing before being really deemed secure. There are a balance of pro and cons, but in the grand battle of big innovations, keeping things secure is a hard problem, because you can't always introduce new things without creating new risks. asm.js relies heavily on the fact that it uses an old, crap language, but since JS engines are heavily optimized, it makes the security problem disappear completely because JS is an old language, so all security problems are already known. It's a problem about how developers practice their job, what they use, how it is deployed and ran by users. Innovation on a massive scale and security never mix well. Also, execution speed and security don't mix very well. The fact android uses java for its app is another demonstration of the easiest path to security.

jlebar 13y ago

Not to pick nits -- it's not the thrust of your argument -- but web browsers have a complex relationship with worse is better today. Yes, browsers started as a hack and it's reasonable to attribute a lot of their success to worse is better "survival characteristics". But having been in the trenches for a few years, I can say that these days, we operate primarily on the MIT approach. For example, WebSQL is worse-is-better; it was rejected in favor of IndexedDB, which is the "right way" (and was a ton more work). At least at Mozilla we were /obsessed/ with making the "right" api; a hack that we felt placed burden on users, like Unix's solution to the lusering problem, would be seriously looked down upon. Indeed I'd argue that the fact that so much work happens in standards bodies may be browsers' biggest concession to the "right way". There are, of course, plenty of modern counterexamples to this too. Like I say, it's a complex relationship...

Ygg2 13y ago
True. I'm not making it look like Worse is Better ALWAYS wins. But it is funny how often it does, contrary to common conceptions. The 'fight' between (P)NaCl and asm.js is by no means over. It's hasn't even begun. I have no clue if NaCl is popular for games, I've saw some on Chrome Store, but they always felt weird. I just like to remind myself that making something is often more important than making it right.

lmm 13y ago

I don't see this as good job Mozilla; I see this as Mozilla using their muscle to keep everyone stuck on Javascript. If Mozilla had been willing to adopt the elegant approach then it would have succeeded. This is a triumph of politics, not of hacking - or to be more charitable, of hacking around politically-imposed constraints rather than fixing them.

BrendanEich 13y ago
From my throne of skulls (https://t.co/CJUs7E3x43 https://t.co/CJUs7E3x43), I'm flexing and posing. Muscle, that's a laugh! Who is the big company with all the money in the world to throw at developers and publishers to use a plugin API supported only in their browser, and still the devs and pubs say no? We heard from another such developer just this week. s/politically-imposed/physics-imposed/ -- fixed it for you.