> I do argue with the following paragraph: I don't see why prototypes-based languages should be more memory compact than class-based

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
        }

Done and done. In Java, I'd do:

    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);

If Java had done anonymous classes right I could have used that to just set the x and y and get a little closer to the NewtonScript example. But the point is: in the proto language I didn't need to declare a class just to override a method. You have to admit there's some elegance and simplicity there. Indeed, my Newtonscript code tended to be very short and simple, whereas my Lisp/CLOS, Python, and Java OO code tends not to be.

I think we may be having a terminology issue here: you seem to define "prototype based" languages as those that have dictionaries for instance variables and methods, whereas class based languages have structs for instance variables and compile-time generated vtables for dispatch.

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.