I wish IO or Self had been more successful, just to see how far one could push a pure prototyping language. IO is more flexible than JS, in that it has (almost) no syntax, just messages to objects, which means you can completely modify the syntax, making DSLs a natural fit for the language.

Right. Sun incorporated Animorphic's work into Self, and later purchased Animorphic and the technology became known as HotSpot.

OK: I was hoping it was going to be something to do with the design of the language as opposed to just to do with the implementation (as any of those languages could have been deployed for the web; especially so given my vague understanding that the web wasn't even Java's most original purpose). (Though I guess I can make up some reasons related to security models that would have been weirder to do in Self or TCL.)

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

Or perhaps neither? It's conventional wisdom these days that composition often works better than inheritance.

In the right context, prototypes can enable Instance-First Development, which is a very powerful technique that allows you to quickly and iteratively develop working code, while delaying and avoiding abstraction until it's actually needed, when the abstraction requirements are better understood and informed from experience with working code.

That approach results in fewer unnecessary and more useful abstractions, because they follow the contours and requirements of the actual working code, instead of trying to predict and dictate and over-engineer it before it even works.

Instance-First Development works well for user interface programming, because so many buttons and widgets and control panels are one-off specialized objects, each with their own small snippets of special purpose code, methods, constraints, bindings and event handlers, so it's not necessary to make separate (and myriad) trivial classes for each one.

Oliver Steele describes Instance-First Development as supported by OpenLaszlo here:

Instance-First Development

http://blog.osteele.com/2004/03/classes-and-prototypes/

He explains how the "Instance Substitution Principal" (where class definitions looked like instance definitions) enables a more seamless granular transition from rapid prototyping to developing a shipping product.

"Instance substitution principal: An instance of a class can be replaced by the definition of the instance, without changing the program semantics."

"The instance substitution principle can be applied at the level of semantics, or at the level of syntax. At the level of semantics, it means that a member can equivalently be attached either to a class or its instance. At the level of syntax, it means that the means of defining a class member and an instance member are syntactically parallel."

"Many prototype-based languages don’t obey the instance substitution principle, either because they don’t have classes, or because class and instance definitions are not parallel. (Typically there’s not a declarative means for defining an instance member.) JavaScript versions 1.0 through 1.5 (the versions in browsers) is also a prototype-based language, but lacks classes as a first-class syntactic entity, and lacks the hierarchical syntax that Java, C++, and LZX use to define class members. JavaScript 2.0, JScript.NET, and Python have a class definition syntax, but don’t use the same syntax to define instance members. For example, contrast the following two Python programs, which parallel the LZX programs above."

I described OpenLaszlo and compared it to Garnet, another early constraint based prototypical user interface system written in Common Lisp at CMU, here:

What is OpenLaszlo, and what's it good for?

http://www.donhopkins.com/drupal/node/124

OpenLaszlo and Garnet both integrated prototypes, constraints, data binding, events and delegates, in a way that (some aspects of which) could be described by the buzzword "Reactive Programming" today.

Here's some discussion about prototypes, Instance-First Development and Lua:

Re: Need good examples of when prototype-based objects are better.

http://lua-users.org/lists/lua-l/2007-10/msg00379.html

Benedek and Lajos discussed "Bottom Up Live Micro Ontologies" including "Instance-First Development" in "Conceptualization and Visual Knowledge Organization: A Survey of Ontology-Based Solutions":

http://real.mtak.hu/31984/1/2197.pdf

2.1.3 Bottom Up Live Micro Ontologies

The structures that emerge in the course of knowledge building that includes discovery and conceptualization typically have all the characteristics we have described in the previous section.

To distinguish the emerging Knowledge Architectures from alternative approaches we propose to refer to them as “Bottom Up Live Micro Ontologies”.

'Bottom up', in compliance with the literature, [62], because they are created in the course of elaborating a concrete domain and 'micro', because the meta terms introduced can affect a single node or any that are linked to a node in a piecemeal agile way and in close contact to the context from which they emerge.

These micro ontologies are usually smaller in size than the so called “local ontologies” in domain modeling [16] because they are amenable to reuse from any context, way beyond the one that gave rise to them.

Using Micro Ontologies it becomes possible to define and manipulate domain knowledge with the aid of meta-level structures introduced on the fly, and these meta-structures can also be treated later as domains of their own right.

Elaborating meta level structures as domains of their own right, leads to additional meta-meta level structures, and the same process can be repeated as far as needed.

So knowledge architecture constructions are “turtles all the way up”.

In a bottom up approach domain specific, as well as meta-level concepts and methods can be developed in a form of “instance first”.

“In instance-first development, one implements functionality for a single instance, and then refactors the instance into a class that supports multiple instances” [13], which is to say we are “going meta”.

Only through live exploration and elaboration of descriptions of exemplars, specific instances of objects of interests, it is possible to develop suitable situated elaborations and conceptualizations that can capture ontologically what “there is” across many instances.

This can be stated as the methodological requirement of the “primacy of bottom up live development”: the characteristics of instance descriptions and the relationship with other instances should not be lost as we construct conceptualizations that are applicable to the class of things that are being described.

Hence, instead of “conceptual atomism” [2] and correspondences between descriptions and some aspects of reality, KO seeks to establish correspondence between the structure including the relationships between instances and their class models in a more abstract sense of ‘images’, or using a current term ‘visual models of reality’, in the spirit of Hertz’s Principles of Mechanics.

In the process of KO the formation of these ‘images’ is however, much closer both historically and methodologically, to Whewell’s “consilience of inductions” trough the “colligation of facts”. [41, p.74].

To paraphrase Ward Cunningham’s quoted dictum: the emerging live, visual knowledge architectures should be “the simplest thing that could possibly work” that enable us to achieve our knowledge goals and intentions in a given situation.

With respect to ontology evolution timelines, it is not only the results of conceptualization that matter but the creation of “knowledge model[s] that preserves audit trails of resource manipulation” as the records of “concept growth can increase the transparency of a research enterprise”. [56, p. 672]

The vision that takes us “beyond ontologies” had largely been explored with the Augmentation System that Engelbart created in his NLS half a century ago on a ‘milli iphone’.

With the millionfold increase of computing resource available even to individuals today, we can embark on developing the means to promote the “culture shift” Ibid.] that could lead to collaborative creation of the ‘great chain of emergent meanings’.

In this quest we need dynamic mechanisms for recognizing and merging alternative conceptualizations.