4 ms·

JavaScript is too dynamic for such analysis. JavaScript at its core is not a very well designed language, and it's a bloody miracle that a JIT can make it usabl

JavaScript is too dynamic for such analysis. JavaScript at its core is not a very well designed language, and it's a bloody miracle that a JIT can make it usable. If you're designing a new language, don't make everything (even arrays!) a hashmap.

j-pb 8y ago
[1]In clojure the array type is basically a hashmap to enable high perf/low memory immutability. So I would say "Yes[1]" ^^
- arghwhat 8y ago
  I would certainly say "no" to having your basic array type be a hashmap as a hashmap is several orders of magnitude slower than an array for all operations on small arrays and for access for all sizes, although there is nothing wrong with also having hashmap and linked list collections if you need O(1) inserts. However, what I was referring to is much worse than that: JavaScript arrays are defined as a normal hashmap with string keys with hooks on assignment to parse the key as a uint32 and update the length property if the value is larger than the current one, and on length assignment iterate over all keys and delete those that successfully parse as a uint32 and has a numeric value larger than the one assigned to length.
  - breatheoften 8y ago
    Wow that’s depressing ...
  - james-mcelwain 8y ago
    I thought dense arrays used linear storage and only fell back to a hashmap when they got sufficiently hole-y.
  - Sawamara 8y ago
    You say all this as if JS's jit engines (V8, chakra, spidermokey, etc) did not destroy "better designed" languages when it comes to speed and efficiency. The only dynamic language that does not pale beyond what is achieved with V8 is LuaJIT.
    - ummonk 8y ago
      How many "better designed" dynamic languages are there even out there? Julia is one such language and is substantially faster than V8, at least for idiomatic code. The problem is that most dynamic languages (like JS) are never designed with speed and efficiency in mind. JS just happens to be the fastest of that bunch (other than Lua) because browser makers have invested substantial effort into making it fast - far more than anyone has put into other dynamic languages.
      - Sawamara 8y ago
        Usual suspects that many people who hate JS seem to champion are are python, lua, ruby. I love Lua personally, but it has its own traps too. Never could get into Python too much, the indentation syntax is killing me :P
        arghwhat 8y ago
        I hate JS with a passion (I worked with it professionally for years, and wrote crypto and compression algorithms, as well as an entire web browser sandbox), but my refuge is in static languages. I no longer see dynamic languages useful for more than bash-like scripting where correctness is uninteresting. :/
      - arghwhat 8y ago
        I don't understand interest in dynamic languages. I have worked with them extensively, but I find them to be handicapped without benefit. However, JS specifically was not designed at all to begin with, but just thrown together, and core concepts have stayed since this first iteration. These core concepts are its primary handicap.
        ummonk 8y ago
        Well, there are some use-cases where Julia is actually faster than compiled code due to being able to compile dynamically generated code on the fly (see https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/7 https://discourse.julialang.org/t/julia-vs-fortran-complaint...) But yes, in general the same lack of static guarantees that makes dynamic languages slow also makes code in dynamic languages hard to maintain. I think a lot of programmers tinker with code in dynamic languages and end up liking them as a result, but don't realize the difficulty of working in such a language in a much more complex codebase.
  - j-pb 8y ago
    I think you kinda missed the point, tbh. You don't need in place memory operations with ridiculous performance in most(tm) applications. On the contrary there are many applications where security is far more important than speed and something that basically embodies remote code execution (browser) is one of those. The fact that JS has made this implementation choice while at the same time being mutable is the true peril, not the specific implementation per se.
- deleted 8y ago
  [deleted]
batmansmk 8y ago
Hmm, looking at the source code, you are partially correct. https://github.com/v8/v8/tree/master/src/objects https://github.com/v8/v8/tree/master/src/objects I can see at least 10 types which are not hash maps. Including all the flavors of Typed Arrays.
- squeaky-clean 8y ago
  That's just how it optimizes their usage under-the-hood, but as far as JS is concerned they are all hash maps. For example, try this: var foo = [1,2,3]; // or `foo = new Array(1,2,3)` also works foo['bar'] = 'test'; console.log(foo); and you get: 0:1 1:2 2:3 bar:"test"
- arghwhat 8y ago
  Ah yes, I had forgotten about Typed Arrays, which is a terrible name for what is in fact a buffer view. The entire arraybuffer/typedarray system was a later (≥IE10 if I am not mistaken?) hack added to make up for the fact that Array and Number are super inefficient for data processing. But regardless of them being a bandaid, you are correct that it is an exception. ArrayBuffer and all its views count 10 types in total, so were they the only exception? If so, I believe my point still stands.

j-pb 8y ago

[1]In clojure the array type is basically a hashmap to enable high perf/low memory immutability. So I would say "Yes[1]" ^^

arghwhat 8y ago
I would certainly say "no" to having your basic array type be a hashmap as a hashmap is several orders of magnitude slower than an array for all operations on small arrays and for access for all sizes, although there is nothing wrong with also having hashmap and linked list collections if you need O(1) inserts. However, what I was referring to is much worse than that: JavaScript arrays are defined as a normal hashmap with string keys with hooks on assignment to parse the key as a uint32 and update the length property if the value is larger than the current one, and on length assignment iterate over all keys and delete those that successfully parse as a uint32 and has a numeric value larger than the one assigned to length.
- breatheoften 8y ago
  Wow that’s depressing ...
- james-mcelwain 8y ago
  I thought dense arrays used linear storage and only fell back to a hashmap when they got sufficiently hole-y.
- Sawamara 8y ago
  You say all this as if JS's jit engines (V8, chakra, spidermokey, etc) did not destroy "better designed" languages when it comes to speed and efficiency. The only dynamic language that does not pale beyond what is achieved with V8 is LuaJIT.
  - ummonk 8y ago
    How many "better designed" dynamic languages are there even out there? Julia is one such language and is substantially faster than V8, at least for idiomatic code. The problem is that most dynamic languages (like JS) are never designed with speed and efficiency in mind. JS just happens to be the fastest of that bunch (other than Lua) because browser makers have invested substantial effort into making it fast - far more than anyone has put into other dynamic languages.
    - Sawamara 8y ago
      Usual suspects that many people who hate JS seem to champion are are python, lua, ruby. I love Lua personally, but it has its own traps too. Never could get into Python too much, the indentation syntax is killing me :P
      - arghwhat 8y ago
        I hate JS with a passion (I worked with it professionally for years, and wrote crypto and compression algorithms, as well as an entire web browser sandbox), but my refuge is in static languages. I no longer see dynamic languages useful for more than bash-like scripting where correctness is uninteresting. :/
    - arghwhat 8y ago
      I don't understand interest in dynamic languages. I have worked with them extensively, but I find them to be handicapped without benefit. However, JS specifically was not designed at all to begin with, but just thrown together, and core concepts have stayed since this first iteration. These core concepts are its primary handicap.
      - ummonk 8y ago
        Well, there are some use-cases where Julia is actually faster than compiled code due to being able to compile dynamically generated code on the fly (see https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/7 https://discourse.julialang.org/t/julia-vs-fortran-complaint...) But yes, in general the same lack of static guarantees that makes dynamic languages slow also makes code in dynamic languages hard to maintain. I think a lot of programmers tinker with code in dynamic languages and end up liking them as a result, but don't realize the difficulty of working in such a language in a much more complex codebase.
- j-pb 8y ago
  I think you kinda missed the point, tbh. You don't need in place memory operations with ridiculous performance in most(tm) applications. On the contrary there are many applications where security is far more important than speed and something that basically embodies remote code execution (browser) is one of those. The fact that JS has made this implementation choice while at the same time being mutable is the true peril, not the specific implementation per se.
deleted 8y ago
[deleted]

batmansmk 8y ago

Hmm, looking at the source code, you are partially correct. https://github.com/v8/v8/tree/master/src/objects https://github.com/v8/v8/tree/master/src/objects I can see at least 10 types which are not hash maps. Including all the flavors of Typed Arrays.

squeaky-clean 8y ago
That's just how it optimizes their usage under-the-hood, but as far as JS is concerned they are all hash maps. For example, try this: var foo = [1,2,3]; // or `foo = new Array(1,2,3)` also works foo['bar'] = 'test'; console.log(foo); and you get: 0:1 1:2 2:3 bar:"test"
arghwhat 8y ago
Ah yes, I had forgotten about Typed Arrays, which is a terrible name for what is in fact a buffer view. The entire arraybuffer/typedarray system was a later (≥IE10 if I am not mistaken?) hack added to make up for the fact that Array and Number are super inefficient for data processing. But regardless of them being a bandaid, you are correct that it is an exception. ArrayBuffer and all its views count 10 types in total, so were they the only exception? If so, I believe my point still stands.