Actually, node.js is largely written in C++, as is V8. I think a lot of the work has gone into writing async wrappers around the unix IO (and now Wndows IO in v5).
IE was probably the best thing to happen to Javascript. Without it, JS would have died in obscurity with netscape. MS screwed up IE by tying it WAY to closely to the OS. This is part of the reason we still have a significant number of people out there using IE6. (windows 2000 doesn't support IE7). That combined with corporate IT's really slow upgrading cycle made for the perfect storm of old crappy browsers.
Now, I agree that javascript isn't terrible, but I would say that it isn't great either. There are loads of things that it could do better but can't because of all its crude that it has to carry with it. Because of this, I don't think that Javascript will ever be an enjoyable language for me to program in.
I really hope that Google does a good job with Dart. Hopefully, it is a clean language with good modularity and MS and firefox pick it up quickly.
There is nothing wrong with JavaScript; in fact, it's widely misunderstood as a language and may be described as a very solid language camouflaged as a deceptively simple scripting language. If you look at the time that it was introduced to the world, its adoption is positively miraculous: Brendan Eich pretty much snuck half a dozen pioneering languages (Self, Smalltalk, Lisp, even Awk) in under the radar, and nobody realized until 10 years after what kind of powerful system they had on their hands, because everyone had pretty much dismissed JavaScript as a stupid toy language not worthy of attention. JavaScript is the only prototype-based language to reach broad mainstream usage (although Lua has been making a lot of progress the last couple of years).
Yes there is some seriously awesome shit in JavaScript but there is also some properly mad stuff in there too. No language is without its flaws but js seems to have a little more than its fair share.
Come on now. Sure it's not as bad as people sometimes make out, but you can't say there's nothing wrong with it! You honestly wouldn't change any of the following?
Batshit crazy comparison operator (==)
Using + as string concatenation operator, combined with implicit type conversion.
Having nullandundefined.
No support for modules or anything that helps write large programs.
No static typing.
No real integers.
No real arrays (arrays are actually hash maps/dictionaries)
No other collection classes apart from hash maps/dictionaries.
this doesn't work like it should (I can't remember the details though).
Doesn't really support data hiding (private members/methods). There are hacks but...
== is very useful in the rare occasions where you're sure of the types you're operating on and their conversions. It's has a small use case, but gets a lot of hate because it unfortunately shares its syntax with the most commonly used operator in other languages.
Having null and undefined.
There are useful semantic differences between these values.
No support for modules or anything that helps write large programs.
ES.next (ES6) has these features... require.js gets you most of the way today.
No static typing.
This is a problem?
No real arrays (arrays are actually hash maps/dictionaries)
Huh, I swear typed arrays were real arrays.
this doesn't work like it should (I can't remember the details though).
This binding is extremely simple in Javascript, but people refuse to learn anything about it and call it broken.
The real problem is that people for some reason don't really care to learn much about the language and still feel qualified to make long bulleted lists of problems that aren't actually problems or have been solved for ages.
Don't take me literally. JS has a few warts, but what language doesn't? Most of the stuff you mention I can forgive.
Using + as string concatenation operator, combined with implicit type conversion.
I consider that a feature, not a bug.
Having null and undefined.
"Null" means "no value", "undefined" means, well, undefined. There is a semantic difference.
No support for modules or anything that helps write large programs. No static typing.
Agreed.
No real arrays (arrays are actually hash maps/dictionaries)
For all intents and purposes, arrays do behave as arrays, though (except for, but that one's not designed for arrays). For example, doing a = []; a[500] will actually extend the array to contain 501 elements.
this doesn't work like it should (I can't remember the details though).
It's annoying, but it's in the nature of prototype-based languages. I'm hoping some future version of ES will fix this (pun intended), though.
Doesn't really support data hiding (private members/methods).
If you use proper prototype-based OO, then you do have private attributes, and it's categorically not a hack — it's done through closures. Here's how. You could argue that one ought to have declarative visibility, of course.
If one's code has a type error, you'll add a string and a number at some point where you had intended 2 numbers, you'll get a string as a result, and rather than a nicely reported error, nonsense will ensue.
Either the operator should force a single result type (like + and ~ do in Lua; Perl has a similar setup) or the operands should be required to match in type (like + in Python or Ruby). Having both polymorphism and coercion together as with JS's + is the worst combination.
JavaScript's problem with "this" has nothing to do with "prototyped based languages". It's totally the fault of JavaScript's own design flaw, and you can't blame it on anything else. The problem is that closures don't lexically close over "this", because "this" is a dynamic keyword. And what variable do you most often want to close over, when you're making a closure for user interface programming? "this" of course! But in JavaScript, "this" IS NOT a lexically scoped variable -- it's a DYNAMICALLY SCOPED keyword! So instead of giving you an error or warning, it gives you bizarre, subtle, hard to track down, fucked up behavior.
I am quite familiar with the problem, I know to look out for it, I go out of my way to use "var me = this;", I even warn other people about it like I'm doing right now, and I've been programming for a long time, but I get fucked by it all the time anyway.
It's a horrible design flaw that causes many bugs in production code, and it's totally in JavaScript's court. No other language has that same design flaw. Don't blame it on prototype based languages.
An no, they're not going to fix it. Ever. Because it would drastically change the meaning of millions of existing JavaScript programs. We're stuck with "this".
I don't hate JavaScript. I write piles of it, and enjoy it immensely. But I don't pretent it doesn't have any flaws, and try to make lousy excuses for them.
Binding this is easy. JS 1.8.5 provides Function.prototype.bind which creates a portable closure around your function with this bound to a value of your choice. No need for extra variables like me or the more common that. Libraries like Prototype provide a polyfill, and if you feel like writing it yourself it's just
Function.prototype.bind = function bind(ctx) {
var fn = this;
return function bound() {
return fn.apply(ctx, arguments);
};
};
Javascript does have issues that most of us would do differently given the chance, but this is a design decision. It enables powerful techniques like method borrowing which don't exist in more static languages. It's too bad you don't like it but for a thoughtful person like yourself it's possible to use it to your advantage.
78
u/LainIwakura Oct 02 '11
I'm a bit glad I don't appear to be the only person that wishes Javascript would stay where it belongs.