On coffeescript's behalf, I've never felt it was a big shortcoming for coffeescript. It really helps to have the actual coffeescript lines, but coffeescript compiles to such a clean javascript, that it is not hard to find the which lines are which.
Emacs mode[1] from Github co-founder Defunkt also makes it really easy to compile a single method/function, so you can easy get the hang of how the compiler works.
But this is great news for production js, which is usually minified, and for other languages, that may not compile down to such a clean js.
I think the big advantage of coffeescript is it gets rid of the whole "implicit global variable" thing. It's not a completely new language (like pyjamas - a python-js converter) just bit of syntactic sugar, which happens to make mistakes a little harder.
I just wish that browsers would allow some bytecode format with linemap/registermap/... data for debugging, and entirely forget about directly supporting languages directly.
Shipping LLVM bitcode is a bad idea. The bitcode format is constantly changing from revision to revision, its JIT is huge and slow so you'd have to rewrite a lot of it, .bc files are enormous, the bitcode format is non-portable, the type system is missing a bunch of stuff like unions, etc.
And modern JavaScript engines largely make it fast enough anyway.
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.
fyi, I may be late to the party, but if you want to debug minified js in firefox and prefer not to wait until its integrated, I have been using this add-on[0] with success.
This feature is also available built-in in Safari and Chrome (in the dev tools, Script pane, look at the bottom buttons bar, its rightmost button is a pair of braces `{ }`. Click on that, it will reformat your source to allow for debugging, the reformatting lasts until you reload the page so it's very handy to try and debug SPA)
I'm not so sure about that because CoffeeScript is a very fast moving language (one of its benefits) and it doesn't make sense to slow down the iteration cycle by integrating it with browsers directly. Then you would have to worry about which CoffeeScript features you could take advantage of, instead of just compiling to the lowest common denominator of JS, so to speak.
Should read or a VM -- I still don't entirely understand how HN determines when you can still edit a post, pretty sure I've edited posts this old before.
CoffeeScript needs to be a fast moving language because it's still being developed. I imagine that, like most languages, it will eventually settle into a fairly stable, mature language spec.
I actually think Coffeescript has one up on Python in some places. Splat assignment, for example, and a slightly simpler idiom for iterating through objects.
I predict a massive surge in CoffeeScript usage over the next couple years.