9 ms·

Every day I learn something new... and stupid.

127 points by acgourley 16y ago

poet 16y ago
From the comments: Ten days to implement the [Javascript] lexer, parser, bytecode emitter (which I folded into the parser; required some code buffering to reorder things like the for(;;) loop head parts and body), interpreter, built-in classes, and decompiler... Ten days without much sleep to build JS from scratch, "make it look like Java" (I made it look like C), and smuggle in its saving graces: first class functions (closures came later but were part of the plan), Self-ish prototypes (one per instance, not many as in Self). That's from Brendan Eich, the guy who created Javascript. Guess you never know when your 10 day project might go big and become something like the assembly for the web. Release early and iterate often seems to hold up quite well here....
- palish 16y ago
  Holy fuck. He did all of that in 10 days? Even with a case of Red Bull, a bottle of Adderall, and a heart full of courage, I doubt most of us could come close to that level of productivity. We'd get bogged down in the details. I know I would.
  - lfx 16y ago
    It's not clear for me if he only coded for ten days. Or he just sad down and thought all algorithms and stuff, and coded in same time. More over there was no social media sites like twitter, facebook, etc, at that time :)
    - BrendanEich 16y ago
      No waterfall process at Netscape, or anywhere near me since the '80s. I designed and coded at the same time. That, plus lack of sleep, show in some of the gaffes. But arguably (Doug Crockford may have argued this) the whole process required JS to make more out of fewer, stronger primitives (first-class functions, prototypes). I know I didn't have time for much else, as I said at the ICFP 2005 keynote. As I told Peter Seibel in "Coders at Work", besides lack of time, I couldn't add anything like (Pythonic, dynamic) classes. That would have encroached on Batman-Java; can't have JS-Robin-the-boy-hostage getting too big for the Netscape/Sun-1995-era-batcave.
      - gruseom 16y ago
        That's really interesting. I think JS is better for those constraints. Seems like a classic disruption: something perceived to be a toy turns out to take over the universe. Some people may cling to the idea that Batman is the "serious" alternative... meanwhile Robin is installed on approximately every fucking computer in the world. It took 10 years to figure out how great the DNA that made it into JS was, but this is what makes web apps possible. We're extremely lucky to have it. Thank you!
  - poet 16y ago
    I've found that there usually is a moment in a programmers technical career where it just clicks. I find that what seems like productivity is almost always a direct result of a higher order of understanding. An analogous situation is your average first year PhD candidate. Initially making some sort of contribution to the field feels overwhelming and almost impossible. But once you've spend a year or two reading papers and having coffee with the leaders in the field, everything comes together. That same PhD student starts to churn out quality papers every 6 months or so. I think back to what it was like watching my dad program in Scheme when I was in high school. I got the same curious and overwhelming feeling then as I do now when working on certain areas of distributed systems. There's no reason to believe that the barriers that grownups face are any less insurmountable than the ones children do. :)
- Revisor 16y ago
  See also interviews with Douglas Crockford and Brendan Eich in Coders At Work for some interesting info.
kristianp 16y ago
So basically, the only numeric type of javascript is a float, which can only represent integers up to 2^53 accurately. Not good if you need an int larger than that.
- tptacek 16y ago
  If you need an int larger than that in JS, you use a bignum library.
  - metageek 16y ago
    ...yes, that would follow. Ow. Ow. Ow. At least the bignum library will be easier to write in JS than in C...
    - glhaynes 16y ago
      You don't have to roll your own, do you?
skybrian 16y ago
This applies to numbers in JSON as well: if one end is JavaScript then you can't assume large integers will survive a round-trip. (GWT emulates longs.)
tptacek 16y ago
Don't miss the comments on this one, since Brendan Eich (of "invented JS" fame) and Zawinsky worked together at Netscape from the beginning.
- nhebb 16y ago
  The comments were more interesting than the article. I had no idea it was created in ten days (if I understood Brendan correctly). I also had a good laugh at jwz's comment: Brendan's house and my nightclub thank us for selling out early and often.
  - mscarborough 16y ago
    It may be old hat at this point but I'd recommend 'Coders at Work', the interview with jwz goes into more depth. http://www.codersatwork.com/ http://www.codersatwork.com/ I didn't know about the incredibly short Javascript creation story until that book.
- deleted 16y ago
  [deleted]
- jacobolus 16y ago
  The one I liked: jwz to brendan eich: “I'm still bummed that I failed to talk you in to making #!/usr/bin/javascript work back then, because I think that we were still in the window where we had a shot at smothering Perl in the crib...”
mmphosis 16y ago
It's like an AI Koan: "One day a student came to Moon and said, 'I understand how to avoid using BIGNUMs! We will simply use floats!' Moon struck the student with a stick. The student was enlightened."
haberman 16y ago
Same is true in Lua (only one number type, which is double by default), though you have the option to compile it to use a different number type instead. http://www.lua.org/pil/2.3.html http://www.lua.org/pil/2.3.html In particular, "long double" on x86 can represent 64 bit integers without loss as well as being floating-point (64 bit mantissa, 15 bit exponent, 1 bit sign). Downside is that it's quite large: 16 bytes.
- wnoise 16y ago
  That's 10 bytes. Is it padded to 16 for alignment?
  - haberman 16y ago
    Yep. sizeof(long double) == 16, at least for me on gcc and Linux. Keep in mind that different compilers implement "long double" differently. According to Wikipedia, MSVC++ just makes it a synonym for "double," but most other compilers on x86 make it this 80-bit "extended precision" floating point.
    - SAHChandler 16y ago
      With MSVC on x86, you can pass /Qlong-double to the compiler for it to "properly size" the long double type :)
- silentbicycle 16y ago
  Also, Lua has a couple bignum libraries available (a GMP wrapper, etc.) - it's explicitly noted in the manual that using doubles for Lua numbers by default is just a pragmatic trade-off, and they can be adapted as necessary.
halo 16y ago
I am surprised that jwz wasn't aware of this. For the record, I think it was a reasonable decision. If you can't make something work well then at least make it simple. JavaScript's treatment of numbers is extremely simple: every number is a double precision floating point number.
- silentbicycle 16y ago
  Yes. While I understand annoyance with floating point accuracy bugs (having been burned by inch/mm conversion and pi/radian bugs before), numbers over 2^53 are large enough that they aren't likely to appear unexpected - if your domain needs bignums, you'll probably know it - so it's a reasonable trade-off.
- acqq 16y ago
  I also don't understand what jwz's problem with the JS numbers is. Once you have bit operators, you can do bit arithmetic. So yes it's a bit slower than when having pure integer types, so what? The JS engines were something like 100 times slower up to recently, and nobody really, really cared until Google did V8. I really think Brendan was right in his decision and I don't get what jwz would like, except to maybe have explicit types in the language, like, hm, JScript.NET or ActionScript. But even there as far as I know ints are 32 bits. 64-bit OS use is still not so common, so at the time the languages were introduced it was the best engineering decision. jwz misses this time.
  - grayrest 16y ago
    > nobody really, really cared until Google did V8 Tamarin and Squirrelfish were benchmark battling before Chrome was publicly released. I think the current focus on performance to be sparked by the CSS selector engine battle between the major JS frameworks.
    - BrendanEich 16y ago
      SpiderMonkey (TraceMonkey in August 2008) was battling SquirrelFish (SquirrelFishExtreme in fall 2008) on untyped JS (Taramin did well only if you added type annotations). V8 was "first" only behind Google's firewall, until Chrome released in early September 2008.
ShabbyDoo 16y ago
Some tea leaf reading.... So, Google built GWT as an abstraction layer over JavaScript which has, fairly effectively (I do a lot of GWT work), made JS little more than a really poorly purposed intermediate form akin to Java bytecode. GWT's pretty fast, but it's certainly limited by the need to express its compiled form in a language designed for humans. It also, interestingly, has a facility for breaking apart a codebase into multiple components for loading in the background. Now, enter Google's Native Client... It allows a program to be expressed in a very low-level representation (a subset of the x86 instruction set) and interact with the DOM/Event model just as does JavaScript (please fact check this). The Google folks are now working on using LLVM inside the Native Client so that programs downloaded over the web may be expressed in its bit code as a means of platform independence. Hmmmm....so what's the difference between a bunch of bit code and a bunch of machine generated and optimized Javascript? Still a lot, but we're getting pretty close. One would have to send his own infrastructure (garbage collector, etc.) along for the ride with the LLVM Native Client scheme, but that seems like a surmountable problem. There's even a project to build a JVM/CLI impl on top of LLVM (http://vmkit.llvm.org/ http://vmkit.llvm.org/). Google seems to be working toward making the browser into a sort of X server, and they're attacking the problem from both ends...a SDK with a community around it in a widely-used language (GWT), and a sandboxed, platform agnostic runtime which will allow for a wide variety of languages/ecosystems to run upon it. With the exception of bleeding-edge games, whatever remaining value native applications for 95% of users will be entirely eroded. We can also observe Google's web printing initiative as yet another means of decoupling most people's computing needs from any particular full-fledged operating system. What I don't understand is how Google will manage to get this scheme adopted as a standard. I believe Mozilla said they aren't in favor of it. And, Microsoft certainly won't play along until they risk having no browser marketshare without it. End users don't care that their computing experience involves DOM and JS -- they just care that it's secure and works well. As a developer, I'd love the freedom of building apps in a language of my choice (presuming it can compile down to the LLVM and run in the browser/Native Client sandbox. Do people on HN think I'm nuts? Is the endgame of the web a universal application "player" as Microsoft has surely feared for over a decade? What is there to lose in such a scheme? One downside for Google would be that machine-readable content is required for search. But, search is so important for app/site developers that all involved would be willing to make accommodations (see Google's published scheme for allowing GWT/AJAX-y apps to be made crawlable).
ggchappell 16y ago
In a comment a bit over a year ago, I noted that JS was being increasingly used as an object code; I asked whether people thought it was suitable for that use. http://news.ycombinator.com/item?id=792547 http://news.ycombinator.com/item?id=792547 There was some disagreement in the replies to my comment, but the general consensus seemed to be that JS is very suitable for use as an object code. But this article makes me wonder. Increasingly, we're compiling HLLs into an object code that only kinda-sorta has integer arithmetic. Is this a good idea? I'm dubious, to say the least. Certainly this property of JS puts some nontrivial constraints on the design of an HLL that can be efficiently compiled into JS. In any case, interesting post.
- gruseom 16y ago
  Since I replied in that thread, here's an update. A year's subsequent experience has diluted my enthusiasm, though not too much (say by 20%). JS is an easy language to generate because it's so flexible. Some of its most loosey-goosey weirdnesses (like the arguments pseudo-array) turn out to work really well for representing other languages' constructs (such as, say, named args). The big downside is if you're trying to do anything computationally intensive. To the extent that you want code to do anything numeric or binary, you're in trouble - forced to work at too high and too kludgey a level. Of course JS wasn't designed for anything like this and the fact that we're even talking about it in this context is a testament to fantastic technical and not just market success. A couple side notes... Actionscript is the inverse case, an abominable language that manages to wreak incredible damage on something pretty good (ECMAScript) in surprisingly few steps -- mainly, as far as I can tell, by trying to turn into something "proper" a.k.a Java, a fate that JS itself was fortunately forced to avoid -- but it provides access to one lower level than JS does, and this is a big deal for some kinds of programs. We're probably going to use Flash (when available) as a computational accelerator for this reason. Second, our results suggest that the real gamechanger here is V8. I know that most of the benchmarks out there show Tamarin and other VMs somewhat competitive with V8. Not in our world. I'm talking a couple of orders of magnitude difference. It's astonishing. If everyone would just use Chrome, we would have no performance problems at all.
  - 16y ago
seles 16y ago
It's like an AI Koan: "One day a student came to Moon and said, 'I understand how to avoid using BIGNUMs! We will simply use floats!' Moon struck the student with a stick. The student was enlightened." Better would be ... Moon then struck the student 100000000000000000-10-1000000000000000000+10 times. The student was enlightened
yycom 16y ago
I've given up on reading jwz. De-css-ing doesn't help and readability only shows the comments.
chadaustin 16y ago
Brendan responds on his blog to set the story straight: http://brendaneich.com/2010/10/should-js-have-bignums/ http://brendaneich.com/2010/10/should-js-have-bignums/

127 points by acgourley 16y ago

poet 16y ago

From the comments: Ten days to implement the [Javascript] lexer, parser, bytecode emitter (which I folded into the parser; required some code buffering to reorder things like the for(;;) loop head parts and body), interpreter, built-in classes, and decompiler... Ten days without much sleep to build JS from scratch, "make it look like Java" (I made it look like C), and smuggle in its saving graces: first class functions (closures came later but were part of the plan), Self-ish prototypes (one per instance, not many as in Self). That's from Brendan Eich, the guy who created Javascript. Guess you never know when your 10 day project might go big and become something like the assembly for the web. Release early and iterate often seems to hold up quite well here....

palish 16y ago
Holy fuck. He did all of that in 10 days? Even with a case of Red Bull, a bottle of Adderall, and a heart full of courage, I doubt most of us could come close to that level of productivity. We'd get bogged down in the details. I know I would.
- lfx 16y ago
  It's not clear for me if he only coded for ten days. Or he just sad down and thought all algorithms and stuff, and coded in same time. More over there was no social media sites like twitter, facebook, etc, at that time :)
  - BrendanEich 16y ago
    No waterfall process at Netscape, or anywhere near me since the '80s. I designed and coded at the same time. That, plus lack of sleep, show in some of the gaffes. But arguably (Doug Crockford may have argued this) the whole process required JS to make more out of fewer, stronger primitives (first-class functions, prototypes). I know I didn't have time for much else, as I said at the ICFP 2005 keynote. As I told Peter Seibel in "Coders at Work", besides lack of time, I couldn't add anything like (Pythonic, dynamic) classes. That would have encroached on Batman-Java; can't have JS-Robin-the-boy-hostage getting too big for the Netscape/Sun-1995-era-batcave.
    - gruseom 16y ago
      That's really interesting. I think JS is better for those constraints. Seems like a classic disruption: something perceived to be a toy turns out to take over the universe. Some people may cling to the idea that Batman is the "serious" alternative... meanwhile Robin is installed on approximately every fucking computer in the world. It took 10 years to figure out how great the DNA that made it into JS was, but this is what makes web apps possible. We're extremely lucky to have it. Thank you!
- poet 16y ago
  I've found that there usually is a moment in a programmers technical career where it just clicks. I find that what seems like productivity is almost always a direct result of a higher order of understanding. An analogous situation is your average first year PhD candidate. Initially making some sort of contribution to the field feels overwhelming and almost impossible. But once you've spend a year or two reading papers and having coffee with the leaders in the field, everything comes together. That same PhD student starts to churn out quality papers every 6 months or so. I think back to what it was like watching my dad program in Scheme when I was in high school. I got the same curious and overwhelming feeling then as I do now when working on certain areas of distributed systems. There's no reason to believe that the barriers that grownups face are any less insurmountable than the ones children do. :)
Revisor 16y ago
See also interviews with Douglas Crockford and Brendan Eich in Coders At Work for some interesting info.

kristianp 16y ago

So basically, the only numeric type of javascript is a float, which can only represent integers up to 2^53 accurately. Not good if you need an int larger than that.

tptacek 16y ago
If you need an int larger than that in JS, you use a bignum library.
- metageek 16y ago
  ...yes, that would follow. Ow. Ow. Ow. At least the bignum library will be easier to write in JS than in C...
  - glhaynes 16y ago
    You don't have to roll your own, do you?

skybrian 16y ago

This applies to numbers in JSON as well: if one end is JavaScript then you can't assume large integers will survive a round-trip. (GWT emulates longs.)

tptacek 16y ago

Don't miss the comments on this one, since Brendan Eich (of "invented JS" fame) and Zawinsky worked together at Netscape from the beginning.

nhebb 16y ago
The comments were more interesting than the article. I had no idea it was created in ten days (if I understood Brendan correctly). I also had a good laugh at jwz's comment: Brendan's house and my nightclub thank us for selling out early and often.
- mscarborough 16y ago
  It may be old hat at this point but I'd recommend 'Coders at Work', the interview with jwz goes into more depth. http://www.codersatwork.com/ http://www.codersatwork.com/ I didn't know about the incredibly short Javascript creation story until that book.
deleted 16y ago
[deleted]
jacobolus 16y ago
The one I liked: jwz to brendan eich: “I'm still bummed that I failed to talk you in to making #!/usr/bin/javascript work back then, because I think that we were still in the window where we had a shot at smothering Perl in the crib...”

mmphosis 16y ago

haberman 16y ago

Same is true in Lua (only one number type, which is double by default), though you have the option to compile it to use a different number type instead. http://www.lua.org/pil/2.3.html http://www.lua.org/pil/2.3.html In particular, "long double" on x86 can represent 64 bit integers without loss as well as being floating-point (64 bit mantissa, 15 bit exponent, 1 bit sign). Downside is that it's quite large: 16 bytes.

wnoise 16y ago
That's 10 bytes. Is it padded to 16 for alignment?
- haberman 16y ago
  Yep. sizeof(long double) == 16, at least for me on gcc and Linux. Keep in mind that different compilers implement "long double" differently. According to Wikipedia, MSVC++ just makes it a synonym for "double," but most other compilers on x86 make it this 80-bit "extended precision" floating point.
  - SAHChandler 16y ago
    With MSVC on x86, you can pass /Qlong-double to the compiler for it to "properly size" the long double type :)
silentbicycle 16y ago
Also, Lua has a couple bignum libraries available (a GMP wrapper, etc.) - it's explicitly noted in the manual that using doubles for Lua numbers by default is just a pragmatic trade-off, and they can be adapted as necessary.

halo 16y ago

I am surprised that jwz wasn't aware of this. For the record, I think it was a reasonable decision. If you can't make something work well then at least make it simple. JavaScript's treatment of numbers is extremely simple: every number is a double precision floating point number.

silentbicycle 16y ago
Yes. While I understand annoyance with floating point accuracy bugs (having been burned by inch/mm conversion and pi/radian bugs before), numbers over 2^53 are large enough that they aren't likely to appear unexpected - if your domain needs bignums, you'll probably know it - so it's a reasonable trade-off.
acqq 16y ago
I also don't understand what jwz's problem with the JS numbers is. Once you have bit operators, you can do bit arithmetic. So yes it's a bit slower than when having pure integer types, so what? The JS engines were something like 100 times slower up to recently, and nobody really, really cared until Google did V8. I really think Brendan was right in his decision and I don't get what jwz would like, except to maybe have explicit types in the language, like, hm, JScript.NET or ActionScript. But even there as far as I know ints are 32 bits. 64-bit OS use is still not so common, so at the time the languages were introduced it was the best engineering decision. jwz misses this time.
- grayrest 16y ago
  > nobody really, really cared until Google did V8 Tamarin and Squirrelfish were benchmark battling before Chrome was publicly released. I think the current focus on performance to be sparked by the CSS selector engine battle between the major JS frameworks.
  - BrendanEich 16y ago
    SpiderMonkey (TraceMonkey in August 2008) was battling SquirrelFish (SquirrelFishExtreme in fall 2008) on untyped JS (Taramin did well only if you added type annotations). V8 was "first" only behind Google's firewall, until Chrome released in early September 2008.

ShabbyDoo 16y ago

Some tea leaf reading.... So, Google built GWT as an abstraction layer over JavaScript which has, fairly effectively (I do a lot of GWT work), made JS little more than a really poorly purposed intermediate form akin to Java bytecode. GWT's pretty fast, but it's certainly limited by the need to express its compiled form in a language designed for humans. It also, interestingly, has a facility for breaking apart a codebase into multiple components for loading in the background. Now, enter Google's Native Client... It allows a program to be expressed in a very low-level representation (a subset of the x86 instruction set) and interact with the DOM/Event model just as does JavaScript (please fact check this). The Google folks are now working on using LLVM inside the Native Client so that programs downloaded over the web may be expressed in its bit code as a means of platform independence. Hmmmm....so what's the difference between a bunch of bit code and a bunch of machine generated and optimized Javascript? Still a lot, but we're getting pretty close. One would have to send his own infrastructure (garbage collector, etc.) along for the ride with the LLVM Native Client scheme, but that seems like a surmountable problem. There's even a project to build a JVM/CLI impl on top of LLVM (http://vmkit.llvm.org/ http://vmkit.llvm.org/). Google seems to be working toward making the browser into a sort of X server, and they're attacking the problem from both ends...a SDK with a community around it in a widely-used language (GWT), and a sandboxed, platform agnostic runtime which will allow for a wide variety of languages/ecosystems to run upon it. With the exception of bleeding-edge games, whatever remaining value native applications for 95% of users will be entirely eroded. We can also observe Google's web printing initiative as yet another means of decoupling most people's computing needs from any particular full-fledged operating system. What I don't understand is how Google will manage to get this scheme adopted as a standard. I believe Mozilla said they aren't in favor of it. And, Microsoft certainly won't play along until they risk having no browser marketshare without it. End users don't care that their computing experience involves DOM and JS -- they just care that it's secure and works well. As a developer, I'd love the freedom of building apps in a language of my choice (presuming it can compile down to the LLVM and run in the browser/Native Client sandbox. Do people on HN think I'm nuts? Is the endgame of the web a universal application "player" as Microsoft has surely feared for over a decade? What is there to lose in such a scheme? One downside for Google would be that machine-readable content is required for search. But, search is so important for app/site developers that all involved would be willing to make accommodations (see Google's published scheme for allowing GWT/AJAX-y apps to be made crawlable).

ggchappell 16y ago

In a comment a bit over a year ago, I noted that JS was being increasingly used as an object code; I asked whether people thought it was suitable for that use. http://news.ycombinator.com/item?id=792547 http://news.ycombinator.com/item?id=792547 There was some disagreement in the replies to my comment, but the general consensus seemed to be that JS is very suitable for use as an object code. But this article makes me wonder. Increasingly, we're compiling HLLs into an object code that only kinda-sorta has integer arithmetic. Is this a good idea? I'm dubious, to say the least. Certainly this property of JS puts some nontrivial constraints on the design of an HLL that can be efficiently compiled into JS. In any case, interesting post.

gruseom 16y ago
Since I replied in that thread, here's an update. A year's subsequent experience has diluted my enthusiasm, though not too much (say by 20%). JS is an easy language to generate because it's so flexible. Some of its most loosey-goosey weirdnesses (like the arguments pseudo-array) turn out to work really well for representing other languages' constructs (such as, say, named args). The big downside is if you're trying to do anything computationally intensive. To the extent that you want code to do anything numeric or binary, you're in trouble - forced to work at too high and too kludgey a level. Of course JS wasn't designed for anything like this and the fact that we're even talking about it in this context is a testament to fantastic technical and not just market success. A couple side notes... Actionscript is the inverse case, an abominable language that manages to wreak incredible damage on something pretty good (ECMAScript) in surprisingly few steps -- mainly, as far as I can tell, by trying to turn into something "proper" a.k.a Java, a fate that JS itself was fortunately forced to avoid -- but it provides access to one lower level than JS does, and this is a big deal for some kinds of programs. We're probably going to use Flash (when available) as a computational accelerator for this reason. Second, our results suggest that the real gamechanger here is V8. I know that most of the benchmarks out there show Tamarin and other VMs somewhat competitive with V8. Not in our world. I'm talking a couple of orders of magnitude difference. It's astonishing. If everyone would just use Chrome, we would have no performance problems at all.
- 16y ago

seles 16y ago

It's like an AI Koan: "One day a student came to Moon and said, 'I understand how to avoid using BIGNUMs! We will simply use floats!' Moon struck the student with a stick. The student was enlightened." Better would be ... Moon then struck the student 100000000000000000-10-1000000000000000000+10 times. The student was enlightened

yycom 16y ago

I've given up on reading jwz. De-css-ing doesn't help and readability only shows the comments.

chadaustin 16y ago

Brendan responds on his blog to set the story straight: http://brendaneich.com/2010/10/should-js-have-bignums/ http://brendaneich.com/2010/10/should-js-have-bignums/