The trouble with Javascript

The result is a system that is fit for neither paradigm. Trying to do work in either one requires a lot of extremely counter-intuitive lines of code that 'you just have to learn'. Unless you want your code to get bogged down such lines, you end up using libraries that allow you to write something that looks more like either Self or Java.

So, the problem isn't that people haven't bothered to learn 'the right way' to do protoclasses in Javascript. The problem is that 'the right way' is stupid. Either make a real prototype system or a real class system (or both!). But the reason that everyone is so unhappy with the state of things is because it sucks.

AFAIK, Self is the progenitor of prototype-based OO. In Self, the way you create a new object is just `someObject copy`. You can dynamically change its prototype later if you want, too. But in traditional JavaScript, you can't do that. You want an object? You need a constructor. Instead of just cloning a prototype, you have to do the whole `function Foo() { blah blah.prototype = someObject blah blah }; myFoo = new Foo()` rigamarole, and there is no standard way to access an object's prototype.

JavaScript has finally got the equivalent of Self's object creation with Object.create, but that is pretty new — and the actual object system still has the whole wonky prototype/constructor/__proto__ mess behind the scenes.

That said, people using JavaScript should be playing to JavaScript's strengths, or picking a different (if not cross-compiled) platform. It's bizarre that people from fundamentally different programming backgrounds complain about these issues. If you don't like C, don't use C. If you don't like JavaScript, write a native application, or cross-compile. There are options, they're in heavy deployment on several major websites, use them. Then everyone can pick the platform they're most comfortable with.

Prototypes are simply more complicated than classes. They change behavior of objects, whereas classes _define_ behavior of objects. The syntax doesn't help it either.

Classical inheritance IS easier to understand compared to how prototypical inheritance was implemented in Javascript --and it's obvious from the examples he gives, and all the workarounds to use prototypical inheritance correctly in all the major JS frameworks.

The implementation details of prototype inheritance should not leak to the language, but in JS, they do.

haxe meets a lot of these criteria and has been around for a while.

For sure it has some oddities with the completion as it can't be sure what the prototypes are, but then it just lists functions from different prototypes which match your prefix.

  function DoStuff(foo)  //<<<<No information what type foo is
  {
    foo.DoA();  //No way to know what methods foo support
    foo.DoB();
  }

I think it's unbelievable that people want to learn about a subject but can't be bothered to read a book about it. This leads to flawed learning at the foundational level, and then avoidable surprises when years (yes, years...) down the road people discover some "unexpected" behavior they should have learned about at the very beginning of the learning journey.

In ye good olden days, when people came to a forum with a stupid question that could be easily solved if the person asking would just bother to read the manual, they used to get a polite RTFM...

Maybe we should start saying RAFB when stuff like that is posted.

Thought: if "prototypal inheritance" really is more powerful/useful/etc., why don't we see efforts to implement it in languages with traditional classes? I've seen dozens of attempts at implementing "traditional" inheritance in javascript, but none goingin the other direction.

...