Prototypes also have some niceties. They are very memory compact, unlike classes and instances. They are elegantly dynamic -- you can add and delete methods and variables, and even change who your prototype is at runtime. Methods in prototypes are very similar to functions, so you don't have to explain the distinctions there.

I think the main problem is that Javascript is such a screwed up language that it has soured people forever on prototype OO and no amount of semantic elegance will fix that.

In answer to your second question, here's the list of languages I know of. Only two are "mainstream", but in a field (CS) where quality is all too often inversely related to popularity, I'm not sure if that's a helpful metric.

1. Self

2. NewtonScript

3. Lua (via metamethods)

4. io

5. IIRC Python implements OO with something approximating prototypes internally but covers them with a class-based sheen when presented to the developer.

One notable difference is that `foo.method` is bound to `foo` in python, but unbound in JavaScript. This leads to lots of `foo.method.bind(foo)` because the former didn't DWIM.

The key similarities in my mind are:

1) In both python and javascript, the class and prototype are exposed and can be called explicitly if desired:

  MyClass.method(my_instance, arg1, arg2)

  MyClass.prototype.method.call(my_instance, arg1, arg2);

  bound_method = my_instance.method

  bound_method = my_instance.method.bind(my_instance);

Can anyone think of any other common ground?

One case that comes to mind is how each language implements (what I call) the continuation pattern. Suppose you want to iterate over the vertices of a binary tree. In JavaScript, you would accept a callback parameter which you call with each vertex. In Python, you would yield each vertex to the caller. These are very different styles and lead you in different directions.

The usual counter example in this discussion goes like: "..but people are already familiar with the concept of categories of objects...".

I do argue with the following paragraph: I don't see why prototypes-based languages should be more memory compact than class-based, and class based languages can have dynamic addition of methods and variables (see ruby), and change of an instance' class (at least since Smalltalk 80 AFAICT).

In most class-based languages, when you create an instance, you allocate memory sufficient for all instance variables defined by its class and superclasses. But in a prototype language, when you create an object, you only allocate memory for the instance variables in which it is different from its parents. That often results in enormous savings, particularly in GUI widgets where you have zillions of instance variables, nearly all of which are left on default settings.

Most class-based languages do this because it allows O(1) lookup of instance variables. Whereas lookup in a prototype language may require wandering up the parent chain until you find the object which defined a given instance variable. That's the tradeoff: lookup speed for memory compactness.

There exist a few class-based languages which don't do this tradeoff. But I have yet to see one of this kind which _doesn't_ basically just implement prototypes underneath. Python is notable here: it doesn't have O(1) lookup to the best of my knowledge, yet doesn't allow the simplicity of prototypes either, so it's sort of the worst of both worlds IMHO.

> and class based languages can have dynamic addition of methods and variables (see ruby), and change of an instance' class (at least since Smalltalk 80 AFAICT).

And CLOS. Sure. But these are exceptions, and don't kid yourself, bolting them into class mechanisms comes at a cost of significant increases in complexity and speed (and loss of the O(1) advantage that classes provide). But in proto languages, you're just adding or changing a dictionary entry. It can't get simpler than that.

> For you first answer, I am not saying you are wrong, but I'd like to see some evidence (e.g. pointer to researches) that prototypes are "much _much_ simpler" than classes and instances.

I'm not sure if simplicity is of interest to academic research. But let me try with an example. In NewtonScript, to make a button which has a different x and y location, text, and override some function (say setText()), I'd say something like this:

    myButton := { 
        _proto: Button, 
        x: 14, 
        y: 15, 
        text: "Hello, World",
        setText() begin here's the code blah blah end
        }

    public class MyButton extends JButton
        {
        public void setText() { here's the code blah blah }
        }

    MyButton foo = new MyButton();
    foo.setText("Hello, World");
    foo.setLocation(x,y);

But this looks like an implementation detail that does not seem related to prototypes vs classes, but more to dynamic vs static ones (e.g. Cecil does prototypes without storing a dictionary in the object, while ruby does classes with dictionaries)

So we may be in agreement, but referring to different things.