Nope, it's real. Maybe it's just overreaction, but after seeing a few submitted stories get upvoted and then fall far off the front-page in minutes, I got the feeling that the old account might be blacklisted in some way. I was going to kick the tires on this one and see if it worked better.
Javascript is a rather terrible bytecode format. It's got all sorts of arcane requirements. (For example, the original text of the function must be preserved), and semantics that make optimization of many constructs quite hard. All numbers are doubles, ffs. It would be hard to do worse as an intermediate language.
"All numbers are doubles" is not something that any self-respecting JIT will emit. All numbers must behave like doubles, but what actually happens is code is agressively type-specialized. So, integer math is emitted, and overflow of 31-bit tagged integers is guarded. If (and rarely) overflow actually happens, then doubles are used.
Yeah, a sane intermediate language may work better, but there is a lot of thrust behind js optimization; the overhead of using JS as an intermediate language, assuming you understand what sort of type-specialization is going on behind the scenes, is really not bad at all.
JS has other fundamental limitations that make it a terrible IR (not being able to choose floating point vs. integer arithmatic is only one of them), there's also the lack of a distinction between hash tables and objects.
You're off base. There is a distinction: objects are not hash tables. JS doesn't have hash tables, not natively. Object behavior might be implemented as a hash behind the scenes, or it might not— V8, for example, does it with hidden C++ classes in a way I don't totally get that's described here: http://code.google.com/intl/sv/apis/v8/design.html#prop_acce... . This has the (purported) benefit of being actually faster than hash lookups. Yes, really.
If you desire some piece of behavior you're used to from hash tables in other languages, you can of course implement that yourself on top of the JS object. Or you could learn to live with abstractions that don't leak.
V8 does not use "hidden C++ classes." It specializes a memory layout for each object layout and uses tracing to optimize property access into direct offset reads/writes.
I'm willing to believe you, but I didn't make that up, I was just cribbing from the link: To reduce the time required to access JavaScript properties, V8 does not use dynamic lookup to access properties. Instead, V8 dynamically creates hidden classes behind the scenes.
I gather a "hidden class" is not an idiom of C++ as I'd assumed, rather something V8 people made up, but that's what they call it.
Until you try to use non-strings as keys. Then you're out of luck. Or if you want to obtain the set of keys or the set of values, in which case you need to write a loop. Ditto if you want to figure out how many items are in the "hash table".
It's not a hash table. These are features which JavaScript objects don't have (in current implementations), but if you need them, you can implement them yourself. Conversely, of course, the prototypal behavior of objects is insanely powerful, and you'd do yourself a favor to stop thinking of them as "hash tables".
I know it's not a hash table. That's the whole criticism anyway because I needed those features. It's pretty stupid that I had to Google for a proper hash table library when something as fundamental as this should be builtin.
Insanely powerful prototypal behavior? I haven't seen anything that I can't already do with Python's or Ruby's object models, but with much simpler syntax. Inheritance in Javascript is a mess, you have to manually write code to copy over the parent class's prototype to the child class, which is why every Javascript framework invents its own wrapper syntax for defining classes.
Inheritance in JavaScript isn't "a mess", it's a paradigm you don't understand[1]. Objects in JavaScript don't have "classes", they have prototypes, so if you want class-like behavior, of course you'll have to implement that yourself. Just like if I want to make key access on a dict fall through to another dict if the key isn't present in Python, I'll have to implement that myself. You may think that's silly, but in a prototypal language that is fundamental behavior.
The `new` keyword was intended to provide the appearance of classes (Java classes, specifically) to make prototypal inheritance less scary to users such as yourself coming from a class-based background, but it's a scam— it creates an object with a prototype, not an instance of a class, and as you're aware it has only caused more confusion about how object inheritance in JS really works.
I find the distaste that new developers have for `__proto__` a little analogous to an inexperienced front-end-only Lisp developer who likes parts of the language, but thinks the whole thing would make more sense without `eval` confusing things at runtime. They're not wrong, exactly, they just misunderstand something fundamental about the way the language actually works. The object prototype is there, it's mutable, and that should be exposed. Ignoring it won't make it go away.
So I'm not surprised you haven't seen a use case for prototypal inheritance, just like that guy hasn't seen a use case for `eval`. You're not going to because you're not looking; you're thinking of objects in JS as having classes, and that's just a fundamental misunderstanding.
For what it's worth, I only write CoffeeScript, which makes everything you think is a hassle in JS easy. In particular, the `class` keyword which has a much prettier, more traditional-seeming syntax to build constructors. But it's a highly leaky abstraction— if you don't understand that what it's compiling to is a function that creates a constructor and sets properties on its `.prototype` one at a time, you will be very confused by the more complex behavior. On the other hand, if you do understand what's going on behind the scenes, it allows for powerful metaprogramming, since you can call methods of the "parent class" or even the prototype itself during the definition.
I understand the paradigm, and I think it's a mess compared to good old OO. I don't want prototypes. With Ruby and Python's OO, I can do everything the prototypal paradigm can, without any of the syntactical insanity, so the argument of prototyping being powerful doesn't hold up.
I know I'm repeating myself now, but JavaScript is not Python, objects are not dicts, etc. Of course whether or not that's poor design is its own conversation.
