What are the advantages that prototype based OO has over class based OO?

Question

Why is class based OO so popular instead of prototype based OO? Do they teach the latter in schools? Though Javascript is prototype based, most people use it mostly function

Answer 1

This question had me intrigued so I went back and read some of the original papers on the concept. It appears to have begun in the mid-1980s in the Smalltalk world but eventually became one of the founding principals of Self. Much later Javascript also adopted it.

The argument put forth in the papers is that it is easier to learn. There is really no technical benefit proposed other than learning. The papers all explain how it is just as expressive as a class-based language but much easier to learn. People naturally think about things in a concrete manner rather than in the abstract. We think of the elephant we saw at the zoo, not a generic "elephant". When we see other elephants, we classify them as differences from the first one. A prototype-based language facilitates this thinking. Think of it as programming by differential.

Is that a sufficient reason to use it in a language? Perhaps. In the 25 years since the idea first started percolating, I would argue that abstracted concepts like class-based OO has not been too hard for most people to learn. On the other hand perhaps there is a need for a blue-collar programming language (like Javascript) which is easier and this may be a way to accomplish that.

If interested, you might start with this paper about self.

Answer 2

If you're looking for someone to point out the advantages/disadvantages of each as an explanation for their popularity, I think you're falling for a fallacy which is for some reason very common in technology - that popularity has something to do with some absolute measure of quality.

The truth is a lot more bland - class based OO is popular because Java uses classic OO, and Sun spent millions of dollars and a very long time building the popularity of Java - making sure people know it's used successfully in corporations, taught widely in universities, and on high school AP tests.

Prototypal/classical OO are just different ways of organizing your ideas. You can implement either one in languages that don't support it natively (Python and Java come to mind, and JavaScript on the other side).

In classical OO, you define an abstract hierarchy of classes for your objects, and then actually work with instances of those classes. In prototypal inheritance, you create a hierarchy of object instances. Although I imagine it might be a bit heretical in both camps, I don't see a reason you couldn't mix the two...

Answer 3

The advantage of prototypal inheritance is that it potentially allows fancy metaprogramming in a straightforward way because the prototype chain is easily manipulated. This is a rather academic advantage because metaprogramming is the wrong answer 99% of the time. As an example, you could have a Javascript Key-Value Observer style data manipulation layer with a special DSL that transparently switched between a local SQLite backing when offline and a REST based server store when online via prototype swapping. I'm not sure it's the best way to do this, but it's the best I can come up with this late. It's not the sort of thing you generally want to do in project code since this sort of indirection is hell to debug once you start getting it going on multiple layers, but it's not bad when you keep it in a library.

Another less helpful advantage is that it allows you to design your own class system. I say less helpful because more or less all javascript libraries have their own slightly incompatible approach to how 'classes' are put together.

There are a lot of people replying who are mixing the inheritance model with the languages implemented in that model. The fact that javascript is dynamic and weakly typed and thus hard to tool has nothing to do with it being a prototypal language.

Answer 4

I think the difference is in the power dynamic (prototyped) language gives to you. Javascript, same like LISP, gives almost unlimited power to a programmer. This power is only limited by programmer's responsibility and the level of his self-confidence. So the discussion is as old as it is - same as static typing vs. typeless. If you consider your programming power and self-discipline are strong enough - go for prototyped style.

Paraphrasing one famous saying:

Talent does what he can (read: class-based), genius does what he wants (read: prototype-based).

Answer 5

I don't know the exact reasons for this, but here are my reasons

I think this argue is the same as Dynamic vs Static, a class is the static definition of the object, that can be used easily to know what to expect from an object, it also helps tooling the languages to have proper intellisense support and documentation because you can easily know what are the different members and methods in the object, another thing is the different paradigm of having the ability to declare private members in the class that doesn't show on the object, this can't be done in the prototype paradigm.

The prototype paradigm is nice, however it lacks the ability for providing information about the methods and members in the object, which makes the tooling harder, and it also makes more sense for dynamic typing programming.

Answer 6

I really don't want to write another article about prototypal inheritance again so I'll just link you to my previous articles. Mind you, they are really long but well worth the read:

1. Benefits of prototypal inheritance over classical?
2. Why Prototypal Inheritance Matters