|
Prototypes and metaclasses are equivalent in power, and both are more powerful than straight classes. You can do things like dynamically change the set of methods that an object responds to with them, something that you have to fake in a class-based system with the State or Strategy pattern. Also, because prototypes are just ordinary objects, you can do even fancier stuff like store the set of possible prototypes in a data structure and dynamically change them based on a lookup. Things like Django's ORM (where all the object has to define are a set of fields as member variables, and then it magically gets a bunch of methods for DB query/insert/update) are trivially easy to define with a prototype-based object system, and you could do even fancier things like add another object to the prototype chain to get JSON serialization, or another one for protobufs, and swap these out at run-time. However, the flip side of this is that more freedom is not always good for more readable software. GOTO, for example, can express any control flow that for/while/do-while/if/switch can and a number that it cannot (coroutines/exceptions/etc.), but as an industry we've moved away from GOTO because most programmers can't hold this flow control in their heads. Prototypes are the same way: they grant a lot of freedom to implement fancy abstractions, but many programmers seem to be unable to understand the resulting abstractions, so they don't find widespread use. Asking for codebases of 100K-1M lines in prototype-based languages is the wrong question. Because prototypes let people define abstractions that other programmers find unreadable, they a.) let you write equivalent software in fewer lines of code and b.) get rewritten in class-based languages as soon as you have more than a handful of programmers working on the codebase. They're much more likely to be used by a small team of hackers who sells their startup for $40M or so and then vests in peace while another team rewrites all their code in Java than by a big company. If you broaden the question to "has anyone ever made significant money working on or with Self", the answer is yes: http://merlintec.com/old-self-interest/msg01011.html (Fun fact: Urs Hoelzle, Animorphic's CTO and sender of the second message in that thread, later went on to become employee #9 and the first executive hire at Google.) |
(I also worked at Google and am somewhat familiar with the Self to HotSpot to v8 heritage.)
Your second paragraph is exactly what I think is wrong with prototypes. There's not enough structure, and not enough constraint. Constraints are useful for reasoning about programs. You might as well just have a bunch of structs and function pointers (and certainly many successful programs are written that way).
Having every application roll its own class system is a terrible idea, in theory and in practice. In practice JavaScript programs end up with multiple class systems because of this. The Lua ecosystem also has this problem.
It's analogous to every library in C rolling their own event loop or thread pool, leading to a fragmenetation of concurrency approaches. Go and node.js both unify the approach to concurrency so every application doesn't end up with 3 different concurrency abstractions.
I don't buy your 3rd paragraph. Python is class-based; it has the characteristic you're talking about with respect to a small team of hackers; and that has been empirically supported by hundreds or thousands of startups being acquired (Instagram, etc.) and even huge companies created (Dropbox).
I honestly think prototypes have failed in the marketplace of ideas and there's a good reason for that. I use metaclasses all the time but not for dynamically changing sets of methods. That seems like a horrible idea. The way I use them is for generating types from external sources like CSV/SQL/protobuf schemas.