4 ms·

Well, the problem (one problem) is that Javascript has no typing system. This makes running valid javascript code super, super slow at times. You can't promise

Well, the problem (one problem) is that Javascript has no typing system. This makes running valid javascript code super, super slow at times. You can't promise to a javascript interpreter that you will always and only use the variable i_am_only_ever_an_integer as an 8 bit integer. This makes lots of things super slow.

ootachi 15y ago
Of course you can promise types to the JS engine. Ints in particular are easy. With modern type-inferring JITs like SpiderMonkey, an expression like "var x = 3;" will infer x to int, and there will be no type checks or unboxing. In more complex cases, you can add "|0". For example: function f(x) { x = x|0; ... } This has the effect of forcing an int interpretation for the argument, and there will be no type checks or unboxing performed thereafter.
- VMG 15y ago
  but you have to admit this isn't very obvious or well documented
- adgar 15y ago
  > Of course you can promise types to the JS engine. Because a variable can always change types, it's actually trivially proven that in a dynamically-typed language, there will always be programs in which the type cannot be inferred.
  - jasonwatkinspdx 15y ago
    Statically.
  - ootachi 15y ago
    Well, statically-typed languages have a "dynamic" type too. Consider void * in C and C++ and Object in Java and C#. You have to downcast to do anything with them. That's the equivalent of what JS is doing with its dynamic typing. The basic difference is that the "dynamic" type is the default in JS, and the static type is the default in statically-typed languages.
    - georgemcbay 15y ago
      The premise of this article is that Javascript's pure dynamic variables lead to slowness. I'm not sure what your point with this post was because if you litter your C/C++ code with non-static casts, it is also going to be much slower than code without casts.
      - ootachi 15y ago
        The parent comment was pointing out that there exist programs in JavaScript in which the types cannot be inferred. All I was saying was that this is not unique to JavaScript, or to dynamically typed languages generally.
- vessenes 15y ago
  Interesting. I didn't know this. I understand that actually getting speed out of JS for binary data is still quite 'hacky' though, for instance Fabrice Bellard used Typed Arrays extensively implementing his Linux-on-Javascript project: http://bellard.org/jslinux/tech.html http://bellard.org/jslinux/tech.html
kaushiks 15y ago
That is not true. I'm not entirely sure what you mean by "no typing system" so I'll go ahead and assume what you likely meant - no static type system. Optimizing code written in a dynamically typed language is a pretty well understood problem (now) thanks to the SELF research at SUN and more recently the V8 Javascript engine. Both VMs employ type profiling at runtime to figure out what the compiler should assume the type of a dynamically typed variable should be. It can then emit code that treats a variable like it always has the profiled type - like a C++ compiler would. When such an assumption is broken at runtime, implementations typically fallback to an unoptimized version of the code (V8) to execute the rest of the continuation. Well written code is expected to achieve type stability pretty fast making the fallback overhead insignificant.

ootachi 15y ago

Of course you can promise types to the JS engine. Ints in particular are easy. With modern type-inferring JITs like SpiderMonkey, an expression like "var x = 3;" will infer x to int, and there will be no type checks or unboxing. In more complex cases, you can add "|0". For example: function f(x) { x = x|0; ... } This has the effect of forcing an int interpretation for the argument, and there will be no type checks or unboxing performed thereafter.

VMG 15y ago
but you have to admit this isn't very obvious or well documented
adgar 15y ago
> Of course you can promise types to the JS engine. Because a variable can always change types, it's actually trivially proven that in a dynamically-typed language, there will always be programs in which the type cannot be inferred.
- jasonwatkinspdx 15y ago
  Statically.
- ootachi 15y ago
  Well, statically-typed languages have a "dynamic" type too. Consider void * in C and C++ and Object in Java and C#. You have to downcast to do anything with them. That's the equivalent of what JS is doing with its dynamic typing. The basic difference is that the "dynamic" type is the default in JS, and the static type is the default in statically-typed languages.
  - georgemcbay 15y ago
    The premise of this article is that Javascript's pure dynamic variables lead to slowness. I'm not sure what your point with this post was because if you litter your C/C++ code with non-static casts, it is also going to be much slower than code without casts.
    - ootachi 15y ago
      The parent comment was pointing out that there exist programs in JavaScript in which the types cannot be inferred. All I was saying was that this is not unique to JavaScript, or to dynamically typed languages generally.
vessenes 15y ago
Interesting. I didn't know this. I understand that actually getting speed out of JS for binary data is still quite 'hacky' though, for instance Fabrice Bellard used Typed Arrays extensively implementing his Linux-on-Javascript project: http://bellard.org/jslinux/tech.html http://bellard.org/jslinux/tech.html

kaushiks 15y ago

That is not true. I'm not entirely sure what you mean by "no typing system" so I'll go ahead and assume what you likely meant - no static type system. Optimizing code written in a dynamically typed language is a pretty well understood problem (now) thanks to the SELF research at SUN and more recently the V8 Javascript engine. Both VMs employ type profiling at runtime to figure out what the compiler should assume the type of a dynamically typed variable should be. It can then emit code that treats a variable like it always has the profiled type - like a C++ compiler would. When such an assumption is broken at runtime, implementations typically fallback to an unoptimized version of the code (V8) to execute the rest of the continuation. Well written code is expected to achieve type stability pretty fast making the fallback overhead insignificant.