VB6 is by no means a good language, but JavaScript is much, much, much worse.
Nor does JavaScript... "use strict";
Being what it is, JavaScript has come on a long way. Saying "avoid this specific feature" does make a language better. The same can be said about specific features of JavaScript (with, eval) but I'm sure you wouldn't make the same argument.
The fact seems to be that people are stuck in their ways and hate on JavaScript because they don't know the language as well they could and they haven't kept up to date with the evolving standards.
The basic fact is that prototype-based OO, for example, is much less practical than class-based OO. Experienced developers comprehend JavaScript's attempt at it just fine. This understanding doesn't change its inferiority, however. This is exactly why so many developers need to compensate for JavaScript's lack of desired functionality in this area by trying to fake class-based OO using the limited functionality that JavaScript does offer.
The same goes for many other aspects of JavaScript. Bad tools are still bad, even in the hands of experts.
I'm not really sure what you're talking about when you mention "evolving standards". If anything, JavaScript's standards haven't evolved well at all. Harmony is only now proposing the addition of core functionality that has been present in other languages for decades now, and should have been in JavaScript from the very beginning, too. JavaScript is merely "evolving" to where it should have been many years ago.
1. Types (classes)
2. Encapsulation (private, protected)
3. Polymorphism (virtuals)
4. Code reuse (inheritance)
While it is much better than prototypal inheritance, it is still less than ideal. On the other hand, there are languages like Haskell and ML which compartmentalize better these concepts:
1. Types: algebraic data types and type synonyms
2. Encapsulation: modules
3. Polymorphism: type constructors (parametric), type classes (ad-hoc, Haskell only)
4. Code reuse: derived type classes (Haskell only), functors (ML only)
The result of providing these features independently from one another is a net increase in flexibility. You can have, say, a module that exports two or more types, and a single function inside that module that can manipulate the internals of both types.
===
Edit: And Rust gets this right as well, of course!
1. Types: structs and enums
2. Encapsulation: modules and crates
3. Polymorphism: generics (parametric) and traits (ad-hoc)
4. Code reuse: trait inheritance and trait instances for generic types
A lot of people who know JavaScript and several other languages very well don't hate on JavaScript. JavaScript has more than it's share of warts, obviously. We all know the story: it was written in a week, etc. It also has more than it's share of good parts, though, and if used correctly it is a very expressive language. In my experience, the haters are more frequently people who don't know the language as well. Clearly our experiences differ. I find it hard to believe, though, that anyone experienced in both languages would claim that JavaScript was worse than PHP, and PHP is still the most common back-end web language.
Actually, you can implement prototypal OO in a class-based language. First of all, you need a single class with two members variables and a member function. The member variables are a pointer or reference to a base object, and a hashmap from strings (member names) to objects (member values). In C++, this would be a std::unordered_map<std::string, boost::any>. The member function is an overload of the subscript operator (operator []) that takes a string argument and checks whether the hashmap contains the string as a key. If string is indeed a key, then its associated value is returned. Otherwise, the same subscript operator is evaluated for the base object and the same string. If there is no base object, then either an exception is thrown or a special undefined value is returned.
The feasibility of doing this is no big surprise. After all, dynamically typed languages are a very, very restricted subset of statically typed languages: http://existentialtype.wordpress.com/2011/03/19/dynamic-lang... . The main reason why users of class-based languages do not do this is that this breaks type safety for very little gain.
Actually, the supposed encoding of class-based OO in a prototypal language is not correct from an operational semantics point of view. In a statically typed OO language, methods and member variables must be known to exist, so they are directly used. The prototypal "encoding" fundamentally relies on testing at runtime whether methods or member variables exist, because it uses the mechanism described two paragraphs above. So it actually does something different than what statically typed class-based OO languages do.
> It also has more than it's share of good parts, though, and if used correctly it is a very expressive language.
For me, an expressive language is not a language that lets me encode hacks (after all, even C can do that), but a language that lets me encode mechanically checkable assurances that my code will work in specific ways. This allows other programmers to reuse my code with full confidence that it will work in the way they expect it to.
Are you talking about JavaScript's "this" keyword? I did not mention it in my preceding comment, because that is an implementation detail of JavaScript functions. I think my point still stands that (static) class-based OO languages are sufficiently powerful to encode the semantics of prototypal inheritance.
> Also, note that I wasn't talking about statically-typed class-based OO specifically. Classical OO exists in plenty of dynamic languages too, so your comments about type systems are kind of out of place.
You have a point there. When they say "classes", I usually think C++ classes or Eiffel classes, but you are right that there are dynamic languages that uses classes, too.
Oh? So in an example where B has a method m, and A inherits from B, how is it that `this` refers to something different when calling B.m() than when calling A.m()? They're the exact same function.
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
Just like in regular class-based OO languages, "this" is an implicit argument of every method that refers to the object on which the method was invoked.
You can even avoid manually doing all the "this" juggling yourself: Make a delegate class, which holds a reference to a method (including its captured variables) and a reference to the "this" object. When a method is retrieved from a an object, actually construct a delegate referencing both the method and the object. (If the method is retrieved after traversing the inheritance chain "upwards", fix the "this" reference along the way "downwards".) Finally, when a delegate is assigned to a variable or as a member of another object, get rid of the "this" reference and assign the method only instead. Client code never gets to see the "this" juggling.
That said, I do need to clarify. I was talking about implementing classical inheritance with prototypal inheritance, and implementing prototypal inheritance with classical inheritance. You can implement either using base language features if you want to create a new object system, but that's not what I was referring to.
The additional constraint of not creating a new object system prevents me from making OO of any kind at all in C, but leaves most scripting languages that implement "classical inheritance" very open to implementing "prototypal inheritance". This is partly because they actually use "prototypal inheritance" and expose a "classical interface" as the primary one, so fiddling with __mro__ feels a little like cheating. If I want to avoid fiddling with the existing __mro__ and build my own, I can override __getattribute__. This certainly doesn't feel like making a new object system to me, but it also doesn't feel substantially different from overriding [] in C++.
But a static OO language can faithfully reproduce the operational semantics of prototypal inheritance.
Edit: Now with method binding that works instead of not working!