undefined | Better HN

story

0 pointsnostrademons8y ago0 comments

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.)

0 comments

chubot8y ago

Thanks for the response, but I wouldn't call that empirical support for prototypes. They took JIT technology developed for Self and applied it to a class-based language, Java. That doesn't mean that prototypes are good for writing programs. It actually indicates the opposite, because the technology in Self that ended up actually being deployed turned out to be something else.

(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.

nostrademonsOP8y ago

Python has metaclasses, and they're used extensively in many of the frameworks that were critical for those startups (Django etc.). They're coming to Javascript too, in the form of ES6 proxies, which have been long awaited.

I actually think metaclasses are probably a better solution than prototypes, because they let you write the majority of your code in a class-based style and only incorporate funky abstractions when they're really necessary, which is typically infrequently. My point is that prototypes are strictly more powerful than (non-metaclass) class-based systems, and that this power lets you build powerful abstractions that can dramatically decrease the number of lines of code you need to write for an initial system.

j / k navigate · click thread line to collapse

0 comments

chubot8y ago

(I also worked at Google and am somewhat familiar with the Self to HotSpot to v8 heritage.)

nostrademonsOP8y ago

j / k navigate · click thread line to collapse