@ramiraz: you make good points, but I'm still not entirely convinced.
Don't add objects
ramiraz wroteyou should not add objects to each other.
This is an annoying limitation, but I could learn to live with it. My problem with coercion is when it happens unwillingly. Sure it's obvious in the examples I gave, but what about adding the results of two functions?
In theory function A and function B both return numbers, so A() + B() should return a number as well. For whatever reason, function A returned an object, would it be too much to ask to throw an exception?
The other solution (which is what I'm doing in JS to circumvent this) is to manually check for the type with typeOf. I shouldn't have to do this, or else at least give me (optional) static typing.
Don't use new
ramiraz wroteYou don't need the new operator unless you want to attach properties to your value, which rarely if ever happens (why would you want to add a property to a number? or a string? or a boolean?)
You seem to assume that all JS code you encounter will be code you are writing. What if you're working on somebody else's code?
new is one example of several constructs in JS that are too ambiguous. This ambiguity is coupled with an extremely permissive interpreter that will do anything to avoid throwing an error (including modifying your data!).
This introduces a high risk of subtle errors that become hard to catch. A language (especially one claiming to be "dynamic") should be easy to read and ideally unambiguous.
Don't use it alone
ramiraz wroteThe recent boom in frameworks and libraries has shown how powerful it can be.
I think it's misguided to cite popularity as an argument for quality (
isn't PHP one of the most popular languages still?). But even so, I think (and this may be a personal bias) that JS success is largely due to the tools it developed, mainly JSLint and the rest of Crockford's suite.
That's a bold claim, especially since, arguably, every popular language comes with its own tools and ecosystem. I still believe that, even in comparison, JS owes a lot to the tools it packs to overcome its annoying quirks.
Conclusion
ramiraz wroteYou can probably find a million things about JavaScript that you don't like, which is ok, everybody has preferences. But to go as far as saying it sucks it just plain wrong. [...] would you blame clay if the potter made defective pottery? It's just a tool and it can be as good as the developer using it.
I don't think that JS sucks completely, just parts of it. And we may all agree that we need to use a subset of the language ("the Good Parts"), but that's only going to limit the
Bad parts, not eliminate them.
I cannot blame clay for defective pottery, but as a potter I can argue that ceramic is better than clay. And just to make it clear: I really don't think JS sucks as a whole. But would I have been happier with something like Lua inside the browser? Oh definitely yes, a billion times yes.
Different notes
(Completely different) Note: You are being overly aggressive, you are moderator damn it you should set an example for others.
My aggressiveness is geared towards the language, I don't mean it to be personal. I apologize if it came out this way, I surely did not intend it to be.