3 ms·

With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a st

by jules 16y ago

With enough effort you can put lipstick on a pig. But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you. Javascript is an historical accident. Let's look at some alternatives if history was different: - Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures. - Java: As an IL to compile down to this would have been better than Javascript. Good points on top of Scheme: unboxed primitive types, static typing means fewer runtime checks. Bad point: lack of tail calls. - ML: excellent choice: has both unboxed primitives and tail calls. I challenge you to find a language that would have been a worse choice than Javascript. It may turn out that by working really hard on smart runtimes and compilers you can get OKish performance out of Javascript in some cases, but that doesn't mean that it's a good choice for an intermediate language. A ML compiler that just translates to LLVM IL as simply as possible without doing any optimizations itself will easily beat the highly optimized Javascript engines we have today.

Robin_Message 16y ago
Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) You are right on integers though, and other types of memory block in general, they are trickier to fix in a javascript engine. Surely the best IL is LLVM IL though, since it was designed so everything can compile down to it.
- silentbicycle 16y ago
  > Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) That sounds like what Self does, too. See the excellent paper, "An Efficient Implementation of SELF" (http://selflanguage.org/documentation/published/implementation.html http://selflanguage.org/documentation/published/implementati...). The Self bibliography page (http://selflanguage.org/documentation/published/index.html http://selflanguage.org/documentation/published/index.html) has a lot of other content applicable to dynamic languages in general, too.
  - wmf 16y ago
    Self and V8 are connected through Lars Bak. http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer) http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
    - silentbicycle 16y ago
      He worked on Beta / Mjølner, too. Neat!
- jules 16y ago
  Yep, sophisticated implementations try to infer the patterns in which objects occur and then dynamically generate classes for them. However this is not without problems, because if you assign to a new slot then you need to change the object's class, it needs to gracefully degrade to when the objects are used as hash tables, etc. LLVM IL would be excellent for speed. The problem is that it's not memory safe (i.e. it allows reading and writing to arbitrary memory locations). NativeClient at Google is trying to solve that. http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/
silentbicycle 16y ago
Tcl would have been worse, probably.
- gloob 16y ago
  Or sed.
  - deleted 16y ago
    [deleted]
- TNO 16y ago
  VBScript
  - blasdel 16y ago
    Except that VBScript is implemented as a DOM scripting language in IE! I've had several mid-end managed switches where the web configuration UI used it and was unusable outside of IE with no sign as to why unless you read the source.
cpr 16y ago
"Worse is better." (Google it.) Javascript is a good enough (New Jersey-style) solution. Why "fix" it?
- silentbicycle 16y ago
  Worse is Better doesn't quite fit here. WiB is about getting a "basically right" prototype out, and then improving it with real world feedback, rather than waiting forever to have a perfect 1.0. With Javascript, unfortunately, it didn't work out so well - a bunch of early bugs (which could have been quickly fixed) were preserved when Microsoft made a bug-compatible clone for IE, and then became part of the ECMAScript standard in 1996. This derailed efforts to improve the language - there is a lot of work on sophisticated implementations now, but the spec itself is buggy. People invoke "Worse is Better" as retroactive justification for all kinds of engineering blunders, but it's a bit more limited in scope. Here you go: http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
  - cpr 16y ago
    I respectfully disagree. "Worse is better" originally applied to the Bell Labs Unix efforts vs the Lisp Machine efforts at MIT and elsewhere. Unix didn't get "fixed" later.
    - silentbicycle 16y ago
      Actually, I think you're right - Javascript was frozen very early and Unix had a while to develop, but the same forces (competing commercial implementations) locked in minor errors in Unix as well. I'd say Unix got more of its warts fixed than JS did, but that's only a difference of degree. Mainly: The whole "Worse is Better" thing works better when you don't get stuck maintaining reverse compatibility with your early releases.
      - InclinedPlane 16y ago
        I'd say Unix and C have more warts, and more serious warts, than Javascript does. But we have come to accept those warts in Unix and C as "the way things are" whereas we generally perceive javascripts warts as such. Arguably the decision to use null-terminated strings in C in order to save one or two bytes of memory per string is an error of much greater than Y2K proportions that we are still paying for.
InclinedPlane 16y ago
x86 was a historical accident, and yet it has become the most popular architecture for personal computers and servers in history. There are plenty of examples of languages that are worse than Javascript for the web. Java being a perfect example. Java and Javascript co-existed on the web for quite some time (in theory they still do). Java is based on a "proper" IL. And yet here we are, talking about some hypothetical new IL to replace Javascript, despite the fact that there is no guarantee it would actually be better, as the historical example of Java has shown us. You need to get more than just the VM "right", there's a billion other factors, Java screwed up, Javascript hit the mark (despite its many other flaws). Perhaps LLVM is the future of web applications, it's too soon to tell. What I do know is that Javascript may not be perfect but it's still fundamentally good, and powerful enough (largely through closures and prototypes) to allow for robust workarounds to its flaws (jQuery, coffeescript, etc.)
bd 16y ago
"But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you." Yup, JS arrays look crazy when you are used to C and pointers (I was shocked when I first found out). That's why WebGL folks had to come up with typed arrays: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html https://cvs.khronos.org/svn/repos/registry/trunk/public/webg... http://weblog.bocoup.com/javascript-typed-arrays http://weblog.bocoup.com/javascript-typed-arrays
sedachv 16y ago
"- Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures." The boxing part is untrue. Even on 32-bit systems (that have word-aligned addressing, which all current 32-bit systems do), you can get 6 arbitrary type tags by using up the three least significant bits of a pointer (6 and not 8 because you use up two of the possible tag values for even/odd immediate integers (fixnums)). Tail calls are overrated, maybe you're thinking about continuations? Those would have been truly terrible - you get all the downsides of concurrency with no benefits. One of the reasons arbitrary crap JS code runs as well as it does is because there's no possibility of concurrency. The browser event-loop model is a good one. "- Java: As an IL to compile down to this would have been better than Javascript. Good points on top of Scheme: unboxed primitive types, static typing means fewer runtime checks." Don't forget: getting sued by Oracle. Java blows in every way compared to JavaScript. If Netscape had put Java instead of JS into Navigator the web would be a very different place today, because no one would have used it [Java]. "ML: excellent choice: has both unboxed primitives and tail calls." In 1995? Give me a break, or a time machine.
- jules 16y ago
  > The boxing part is untrue. You're right. Scheme implementations usually have unboxed fixnums and other types. However Scheme systems do not usually support user defined unboxed objects, like C#, C and ML do. > Tail calls are overrated, maybe you're thinking about continuations? Those would have been truly terrible I agree, I did mean tail calls. Tail calls may not be so good for programming with, but they are good for compiling to, because you can easily encode your control structures like while, for, until, state machines and more exotic forms of looping to them. You can also compile (parts of) code in continuation passing style without blowing the stack, which is hard to do efficiently if you don't have tail calls. The reverse is not true, you cannot easily express tail calls on top of the usual control structures like while. This is why Scala and Clojure still don't have support for tail calls. > Java blows in every way compared to JavaScript. If Netscape had put Java instead of JS into Navigator the web would be a very different place today, because no one would have used it [Java]. I'm not arguing that Java is better than Javascript for programming in. It's just a better target for compilers. > In 1995? Give me a break, or a time machine. Do you have any arguments to back up why ML would not be a better IL than JS? It seems to me that you are arguing that these languages are not better than JS for programming in, but that is not what I claimed.

by jules 16y ago

Robin_Message 16y ago

Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) You are right on integers though, and other types of memory block in general, they are trickier to fix in a javascript engine. Surely the best IL is LLVM IL though, since it was designed so everything can compile down to it.

silentbicycle 16y ago
> Just to note though: Javascript in fact doesn't require representing objects as hash tables. For example, the V8 javascript engine represents objects as instances of classes, more or less exactly how C++ would do it (the build the class definitions automatically in the background.) That sounds like what Self does, too. See the excellent paper, "An Efficient Implementation of SELF" (http://selflanguage.org/documentation/published/implementation.html http://selflanguage.org/documentation/published/implementati...). The Self bibliography page (http://selflanguage.org/documentation/published/index.html http://selflanguage.org/documentation/published/index.html) has a lot of other content applicable to dynamic languages in general, too.
- wmf 16y ago
  Self and V8 are connected through Lars Bak. http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer) http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
  - silentbicycle 16y ago
    He worked on Beta / Mjølner, too. Neat!
jules 16y ago
Yep, sophisticated implementations try to infer the patterns in which objects occur and then dynamically generate classes for them. However this is not without problems, because if you assign to a new slot then you need to change the object's class, it needs to gracefully degrade to when the objects are used as hash tables, etc. LLVM IL would be excellent for speed. The problem is that it's not memory safe (i.e. it allows reading and writing to arbitrary memory locations). NativeClient at Google is trying to solve that. http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/

silentbicycle 16y ago

Tcl would have been worse, probably.

gloob 16y ago
Or sed.
- deleted 16y ago
  [deleted]
TNO 16y ago
VBScript
- blasdel 16y ago
  Except that VBScript is implemented as a DOM scripting language in IE! I've had several mid-end managed switches where the web configuration UI used it and was unusable outside of IE with no sign as to why unless you read the source.

cpr 16y ago

"Worse is better." (Google it.) Javascript is a good enough (New Jersey-style) solution. Why "fix" it?

silentbicycle 16y ago
Worse is Better doesn't quite fit here. WiB is about getting a "basically right" prototype out, and then improving it with real world feedback, rather than waiting forever to have a perfect 1.0. With Javascript, unfortunately, it didn't work out so well - a bunch of early bugs (which could have been quickly fixed) were preserved when Microsoft made a bug-compatible clone for IE, and then became part of the ECMAScript standard in 1996. This derailed efforts to improve the language - there is a lot of work on sophisticated implementations now, but the spec itself is buggy. People invoke "Worse is Better" as retroactive justification for all kinds of engineering blunders, but it's a bit more limited in scope. Here you go: http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
- cpr 16y ago
  I respectfully disagree. "Worse is better" originally applied to the Bell Labs Unix efforts vs the Lisp Machine efforts at MIT and elsewhere. Unix didn't get "fixed" later.
  - silentbicycle 16y ago
    Actually, I think you're right - Javascript was frozen very early and Unix had a while to develop, but the same forces (competing commercial implementations) locked in minor errors in Unix as well. I'd say Unix got more of its warts fixed than JS did, but that's only a difference of degree. Mainly: The whole "Worse is Better" thing works better when you don't get stuck maintaining reverse compatibility with your early releases.
    - InclinedPlane 16y ago
      I'd say Unix and C have more warts, and more serious warts, than Javascript does. But we have come to accept those warts in Unix and C as "the way things are" whereas we generally perceive javascripts warts as such. Arguably the decision to use null-terminated strings in C in order to save one or two bytes of memory per string is an error of much greater than Y2K proportions that we are still paying for.

InclinedPlane 16y ago

x86 was a historical accident, and yet it has become the most popular architecture for personal computers and servers in history. There are plenty of examples of languages that are worse than Javascript for the web. Java being a perfect example. Java and Javascript co-existed on the web for quite some time (in theory they still do). Java is based on a "proper" IL. And yet here we are, talking about some hypothetical new IL to replace Javascript, despite the fact that there is no guarantee it would actually be better, as the historical example of Java has shown us. You need to get more than just the VM "right", there's a billion other factors, Java screwed up, Javascript hit the mark (despite its many other flaws). Perhaps LLVM is the future of web applications, it's too soon to tell. What I do know is that Javascript may not be perfect but it's still fundamentally good, and powerful enough (largely through closures and prototypes) to allow for robust workarounds to its flaws (jQuery, coffeescript, etc.)

bd 16y ago

"But really, an IL that doesn't support integers? An IL where a member field access may involve looking up a string in a hash table instead of being a single machine instruction? Propose that as an IL to a compiler guy and they'll laugh at you." Yup, JS arrays look crazy when you are used to C and pointers (I was shocked when I first found out). That's why WebGL folks had to come up with typed arrays: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html https://cvs.khronos.org/svn/repos/registry/trunk/public/webg... http://weblog.bocoup.com/javascript-typed-arrays http://weblog.bocoup.com/javascript-typed-arrays

sedachv 16y ago

"- Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures." The boxing part is untrue. Even on 32-bit systems (that have word-aligned addressing, which all current 32-bit systems do), you can get 6 arbitrary type tags by using up the three least significant bits of a pointer (6 and not 8 because you use up two of the possible tag values for even/odd immediate integers (fixnums)). Tail calls are overrated, maybe you're thinking about continuations? Those would have been truly terrible - you get all the downsides of concurrency with no benefits. One of the reasons arbitrary crap JS code runs as well as it does is because there's no possibility of concurrency. The browser event-loop model is a good one. "- Java: As an IL to compile down to this would have been better than Javascript. Good points on top of Scheme: unboxed primitive types, static typing means fewer runtime checks." Don't forget: getting sued by Oracle. Java blows in every way compared to JavaScript. If Netscape had put Java instead of JS into Navigator the web would be a very different place today, because no one would have used it [Java]. "ML: excellent choice: has both unboxed primitives and tail calls." In 1995? Give me a break, or a time machine.

jules 16y ago
> The boxing part is untrue. You're right. Scheme implementations usually have unboxed fixnums and other types. However Scheme systems do not usually support user defined unboxed objects, like C#, C and ML do. > Tail calls are overrated, maybe you're thinking about continuations? Those would have been truly terrible I agree, I did mean tail calls. Tail calls may not be so good for programming with, but they are good for compiling to, because you can easily encode your control structures like while, for, until, state machines and more exotic forms of looping to them. You can also compile (parts of) code in continuation passing style without blowing the stack, which is hard to do efficiently if you don't have tail calls. The reverse is not true, you cannot easily express tail calls on top of the usual control structures like while. This is why Scala and Clojure still don't have support for tail calls. > Java blows in every way compared to JavaScript. If Netscape had put Java instead of JS into Navigator the web would be a very different place today, because no one would have used it [Java]. I'm not arguing that Java is better than Javascript for programming in. It's just a better target for compilers. > In 1995? Give me a break, or a time machine. Do you have any arguments to back up why ML would not be a better IL than JS? It seems to me that you are arguing that these languages are not better than JS for programming in, but that is not what I claimed.