Go and Rust – objects without class

That's true, but I just have to ask: so what? I, for one, don't subscribe to the theory that popularity equals quality. Although both C and C++ are immensely popular in terms of code written in them that doesn't mean they're the last word in language design.

> No other languages today can compare to them, and the ones that try still depend very heavily on one or both.

I don't understand what you mean by "compare to them". If you mean in terms of features - sure there are languages more advanced. If you mean in terms of popularity then I can only say I find such comparisons meaningless.

> Now, if we could reliably implement class-based OO systems comparable to, > or even better than, those found in Java, C#, C++, Python, Ruby, and Smalltalk, > for example, then maybe we could say prototype-based OO is more expressive.

We can do this (modulo "reliably", which I don't understand what you mean by) and that's the problem. You yourself explain this:

> However, all we end up with are multiple half-assed

That's exactly the case. Java, C++, Python and Ruby are extremely incompatible with each other. No wonder that JS implementations of ideas taken from those languages are still incompatible - although less so than originals between themselves. It's also not that strange that they are incomplete - given that everything you'd like to do in class-based system you can do with prototypes there is simply no need for frameworks being complete.

Can you post a few examples of what is possible in Java and not possible in JavaScript?

Also remember that language designers can alter syntax to better support their systems, so we need to exclude syntax from comparison.

> It's much more effective to implement prototype-based OO systems using class-based OO languages.

I don't know if it's impossible, but your examples are flawed. Of course you can write any language in any language, like JS VMs are. But that's completely different matter, I was talking about using the language itself in a prototype based manner. I suspect that, due to static and low-level nature of classes in C++ it's completely, utterly impossible to replicate JS object system inside C++. That you can write interpreter that implements this system is obvious and not interesting at all.

As a counter example, in Python you could, with careful use of metaclasses and implementation details of classes and objects create objects whose methods lookup order and semantics of would be the same or close to those of prototype based JS - in the language itself.

=======

Your arguments fail to prove that prototype based-ness somehow fails. It does not, in itself, fail in any way. As I wrote above, show what can be done with classes (single inheritance model) that cannot be replicated using JS or better IO prototype semantics - that would be convincing. The fact that JavaScript development is a mess - I won't deny it - proves nothing about prototypes and only a bit about JS.

By the way, have you tried Haskell, OCaml or F# and Erlang?

That says a lot about the lack of alternatives for code that must run in a browser and next to nothing about the merits of prototypes.

I have the fortune to work with a bunch of people that worked on Self, or worked with people that did. Many of them told me that after all of that experience, the conclusion they came to was that prototypes don't really work well in practice, even when you have multiple parents like Self. (JS lacks that, which makes it even more painfully limited.)

Meanwhile, many JS luminaries, people who understand every corner of the language, are working hard to add class syntax to ES6 (, or defining transpilers that support it (Erik Arvidsson with Traceur, Jeremy Ashkenas with CoffeeScript).

I find prototypes interesting. I've implemented my own prototype-based language from scratch to understand them better. As soon as I had it working and started writing code in the language, the first thing I found myself wanting was to add classes to it.

Nope. A subclass is usually (not always!) a subtype, not the other way round. Or, more specifically (and accurately), most statically-typed class-based OO languages treat subclasses in their type systems as subtypes by default, i.e., they assume that a subclass instance can act as an instance of its superclass, LSP-wise. This, I believe, is as accurate statement as one can make (on this level of generality).

The “is-a” relationship is saying “for all instances I of X, I is an instance of Y” which is essentially the definition of superset. That is what the Liskov Substitution Principle is about.

It's a definition of a superset, if Y is the superset and X is the subset.

In C++ and other languages with support for object-oriented programming, a subclass is not necessarily a supertype: virtual functions can throw “I don’t make sense in this derived class”.

That's a part of why I believe that static typing doesn't make too much sense when it comes to OO languages (with (sub)classes). If static typing is supposed to take care of subtype assignability statically and the semantics of the behaviour of derived classes can break the LSP assumptions, static typing becomes sort of worthless.