Yes, to hack up, so what? Non-prototype object systems can also be written simply and in a small footprint, and have a reasonably small description.
A prototype object system is barely one step above pretending that a hash table is an object.
2. It's powerful.
It's not expressive of OOP concepts and creates spaghetti code. All OOP is monkey patching: make this object like that one, but patch this.
3. It leads to smaller, less redundant code.
Because you're not properly specifying classes, which serve as an important guide to the structure of your program, and provide a locus of control.
We can achieve smaller and less redundant code by identifying every function that is only called once and manually inlining it, so there is no name that is redundantly mentioned two places in the program. That doesn't mean it's a good idea.
4. It's dynamic and hence it's better for dynamic languages.
This point is subtly fallacious. Dynamic languages also have non-prototype based object systems, which are also dynamic and good for those languages. There is good dynamic and there is bad dynamic.
Under prototype object, it's hard to do certain important dynamic things like redefine the method of a class such that all objects of that class (existing instances) use the new method.
Non-prototype objects systems in dynamic languages can easily support prototype-like mechanisms without those being the main mechanism of organization of OOP programs.
Failing that, in any dynamic language that gives you hash tables, you can ignore the fine OOP system and do prototypes with hashes.
Yes, to hack up, so what? Non-prototype object systems can also be written simply and in a small footprint, and have a reasonably small description.
A prototype object system is barely one step above pretending that a hash table is an object.
2. It's powerful.
It's not expressive of OOP concepts and creates spaghetti code. All OOP is monkey patching: make this object like that one, but patch this.
3. It leads to smaller, less redundant code.
Because you're not properly specifying classes, which serve as an important guide to the structure of your program, and provide a locus of control.
We can achieve smaller and less redundant code by identifying every function that is only called once and manually inlining it, so there is no name that is redundantly mentioned two places in the program. That doesn't mean it's a good idea.
4. It's dynamic and hence it's better for dynamic languages.
This point is subtly fallacious. Dynamic languages also have non-prototype based object systems, which are also dynamic and good for those languages. There is good dynamic and there is bad dynamic.
Under prototype object, it's hard to do certain important dynamic things like redefine the method of a class such that all objects of that class (existing instances) use the new method.
Non-prototype objects systems in dynamic languages can easily support prototype-like mechanisms without those being the main mechanism of organization of OOP programs.
Failing that, in any dynamic language that gives you hash tables, you can ignore the fine OOP system and do prototypes with hashes.