Prototype Languages are a Failed Experiment

I remember reading long ago - maybe from Hejlsberg? - that Java's checked exceptions were a "failed experiment". Most people agree, and as much as I still like checked exceptions (and I can back that with tons of code...), it's a fact, in the sense that Java's experiment failed to convince most people - which you can assert by looking at newer languages. Not a single other programming language adopted this trait of Java. Language designers make decisions with various motivations, but you won't find checked exceptions in any kind of post-Java language, no matter if it's created by PhD researchers, big corporations, free software hackers with their different itches, or monkeys with their infinite typewriters.

The failure is bigger: I have fond memories of Eiffel, I didn't use it professionally but played a bit, Meyer's OOSE book was my first Bible (I mean it, as in, adoration-to-sacred-commandments). But the heretics have won and DbC is a mostly dead idea. Heck, even Java 1.4's modest assert is virtually unknown and unused.

Now, what can we tell about prototype-based languages - those where behavior is reused by cloning objects that first define it? A bit like Java for checked exceptions, #Javascript is the big champion of the prototype paradigm. It's the single successful and mainstream language, ever, to espouse the idea. Self and Cecil were research languages; Lua is successful but not mainstream, and its niche (game scripting) doesn't need programming-in-the-large qualities.

More important than that is looking at the "legacy" of Javascript: Languages designed after Javascript, remarkably ones that compete[d] in the same area. I could name VBScript, Curl, ActionScript, F3 / JavaFX Script, Silverlight (several languages although none especially created for that)..., and of course Google's new #Dart. Not a single of these languages is prototype-based. Flash's ActionScript 1 was, but this is the first thing Adobe fixed - v2 introduced class-based OO as a layer over prototypes, and v3 embraced classes for good (prototypes are still available but definitely a second-class, legacy feature).

[Personal note: I've used Pic%, a prototype-based OO language built on top of Pico, that one being a Scheme-like academic language. I was lucky enough to have Pico's creator Theo D'Hondt as professor in my MSc (EMOOSE ftw!), where I spent long nights in assignments to modify Pic%'s metacircular implementation.]

Java's checked exceptions (and everything else from Java) had a chance to mature: production-grade implementations, tooling, community / ecosystem. This is critical to really judge language innovation - if some language is never widely adopted, advocates of its unique qualities may claim they were just not developed to full potential. Javascript has no such excuse today; the enormous investment from all Web industry placed Javascript in a very select club. There is no shortage of runtime technology, tooling (IDEs etc.), libraries. High-performance VMs are a late and still ongoing development, but it's safe to state that all low- and medium-hanging fruit were already harvested, the top VMs are already in the diminished-returns curve. Same goes for tooling and other pieces of the puzzle, everything is already mature i.e. don't expect any major improvements from now. Unless new releases of the language make it easier to optimize, refactor, modularize, etc.; but then, that's not the same language. ES5 (Harmony), the next major release of Javascript, is yet another Javascript derivative to put prototypes in the past. Its support for real class-based OO and optional static typing, like ActionScript v2, give the finger to the language's roots, relenting from pressure from end-users and compiler/tool writers alike.

Wikipedia summarizes the criticism for prototype-based languages, but misses one item that seems important to me: prototypes are highly coupled to dynamic typing. I know of no prototype-based language that's fully and strictly static-typed; I mean not using qualifications like "optional", "lenient", "runtime", "partial", etc. Class-based languages, on the other hand, can be perfect matches for either static or dynamic typesystems (or anything in between). Henry Lieberman's seminal paper on prototype languages shows that delegation is more powerful than inheritance; this has been widely read and quoted as "prototype languages are more powerful than class-based", but that's bollocks, remarkably with the modern crop of OO languages and techniques, that both support delegation pretty well and deemphasize inheritance compared to the first-generation OOPL's. Today, the comparison boils down to the fact that prototype-based languages are much less flexible in the critical aspect of compatibility with different typesystem strategies.

Prototype, n., from greek "primitive form". RIP.
Shared publiclyView activity
Related Collections