HN Explorer

Ask HN: Why isn't prototype based object orientation more popular?

4 points by jetti ↗ HN
I'm thinking of creating a programming language that uses prototype OOP but have noticed there aren't a lot of languages (compared to that use class oriented object orientation). Heck, it even seems like EMCAscript is getting away from prototype based OO with their new class in ES6.

3 comments

[ 3.9 ms ] story [ 14.8 ms ] thread
andrewmcwatters
I think it's just not intuitive for me. HOWEVER, that being said, I think based on my experience, all of the languages that had solid prototypal OOP, provided the foundation for class-based OOP, too. So you really get the best of everything.

I think you should go forward with your decision. I think the foundational designs probably matter more: providing flexibility to those who desire either is a tremendously powerful thing.

jetti
>HOWEVER, that being said, I think based on my experience, all of the languages that had solid prototypal OOP, provided the foundation for class-based OOP,

See, I wouldn't want to add class-based OOP as I feel that would "soil" the language as one could just completely ignore the prototype aspects and use it as a class-based language.

enkiv2
Prototype-based object orientation, while it's conceptually simpler & cleaner, violates a lot of the design assumptions taught (and mandated to be taught) by computer science programs. People who learned computer science in high school or college in the United States from mid-tier programs were learning material mandated by a couple accreditation agencies focused on the AP curriculum; this material was originally constructed for C++ and was adjusted to be about Java in the late nineties, and it focuses on object orientation in terms of encapsulation and inheritance.

Someone who is self-taught or who learned to code via a different curriculum (say, one based around scheme like MIT's, or one based around javascript) naturally will think of object orientation in terms of something that a programmer implements, and will see prototype-based OO as easier to implement and easier to predict, since inheritance (particularly multiple inheritance) can quickly get complicated. But, this mandated curruculum based around strongly-typed compiled languages with class-based OO and a nearly ideological focus on the (mostly imaginary) benefits of inheritance has mass-produced students who are primed to think of class-based OO as the natural state of things rather than as a tool that is only sometimes appropriate.

In any prototype language, adding classes is trivial (it's just a matter of treating some objects as inviolate), and adding inheritance and even simple forms of multiple inheritance (if you have access to metatables / can override member lookup routines) isn't terribly difficult. The opposite is generally not true. But, again, this focus on class-based OO is largely not based on strategic thinking, but instead upon mechanisms designed to make sure large numbers of entry-level programmers are part of a specific monoculture. (This has succeeded: consider the proliferation of Java -- a language that is only very rarely an appropriate tool for any job.)