[wvenable]

> What attracts me most is that prototype systems are conceptually simpler in an Occam's Razor sort of way.

That's true, but I find you end up having to make the difference. Yes, prototype inheritance is conceptually simpler but in practice it's more complex. In JavaScript, for example, OO code tends to be harder to follow and includes more boilerplate code. You have to make up for the simplicity of the platform in order to get your work done. In more traditional OO languages, inheritance might be more limited but it's also more straight forward and easier to implement, calling parent class methods is build in, and the "this" reference works consistently.

[wkornewald]

JavaScript has the worst form of prototype inheritance I've ever seen. All the boilerplate code is not the fault of prototypes, but of JS. Also JS prototypes are insanely limited. You can't have multiple delegates and you can't change delegates at runtime. JavaScript's inheritance actually smells like some broken state between class based inheritance and prototypes. It has none of the advantages of either and combines the disadvantages of both. I'll make a longer blog post explaining how prototypes are supposed to work and what their real advantages are. You'll see that JS inheritance is a huuuge design failure and that nobody should ever mention prototypes and JavaScript in the same sentence.

[wvenable]

I've studied other prototype languages (Io for example), but JavaScript is the only one that I use on a regular basis or in a professional capacity. I imagine for the vast majority of developers, JavaScript is their only introduction to prototype inheritance.

[wkornewald]

Yeah, and that's a real shame because those developers will get a really bad impression of prototypes (unless they only use one of the class emulation libs and never learn about prototypes, of course).

[btilly]

In more traditional OO languages, inheritance might be more limited...

Explain.

Class based inheritance, with a good metaprogramming model, is strictly more flexible than prototype based inheritance because you can easily implement the latter. The shortest implementation that I know of is the following Ruby one:

  Proto = Class.new(Class)    # Beware: magic.
  def Proto.clone
      Class.new(self)
  end

You can find out more about how to use that at http://snippets.dzone.com/posts/show/3378.

[troels]

Well, Ruby's classes are open. So while they are called classes, they are much more similar to prototypes than, say, Java's classes are.

[btilly]

FYI, Ruby's class model is almost directly copied from Smalltalk, which is the classic object oriented language, and is where the phrase "object oriented" was invented. Therefore there are no grounds to suggest that Ruby somehow does not have "real" classes because they don't look like Java's.

[troels]

I weren't proposing any form of value with my statement. Just pointing out that on the scale of {run-time..compile-time} object model, Ruby is closer to the run time end.

[wladimir]

Javascript also severly biased me against prototype-based and for class-based inheritance.

Then again, Javascript's implementation of anything is awful. The only reason people use it, is because there is no way around it for web client programming. I'm pretty sure we shouldn't take it as an example.

[russellallen]

This may be true but if it is I think it must be specific to JavaScript. It's the opposite to my experience with Self, which is that prototypes help my code be clearer and simpler.