Prototype-based Languages and Design-Tension

Stefan Tilkov and Steve Vinoski wonder why JavaScript hasn’t really taken off. The wikipedia entry on Prototype-based programming suggests that the

community of software developers is not familiar with them, despite the popularity and market permeation of JavaScript. Further, as prototype-based systems are relatively novel, and few and far between, best practices for software development using them have not become widespread.

I’d argue that every language design is an exercise in the balance of tension between structure and sloppiness.

Statically-typed languages are well and good in terms of verifiability, but when taken too far, like in the case of generics, result in programs that are very hard to read.

Prototyped language is on the other end of flexibility. It enforces no structure. Hence, structure becomes dictated by convention and known body of good practices. I believe this is why people work so hard at reimplementing OO in JavaScript – people are trying to narrow down the flexibility of the environment so that it can perform something useful.

A multiparadigm language is too versatile to be evaluated as good or bad in it’s own right, and allows a designer to vacillate between too many future possibilities. Just as assembly programming evolved calling conventions so that some structure can be imposed on programs, a prototype-based programming language is not a usable language until it cedes some flexibility or gives weight to particular practices.

I believe the popularity of Python can be partly attributed to a designer who was brave enough to commit to making some decisions about how the language is to be used in general (a little bit functional, and bit more OO and enforcing style through indentation), but yet remained flexible about allowing some seat-of-your-pants programming tricks like replacing methods on the fly or assigning new methods to existing objects.

There are other examples of successful design tension in real life.

• Dan Bricklin’s VisiCalc took off because the grid enforces a basic structure in a programmable document, yet within the limits of the grid, provided limitless ways computing can be carried out.
• The blog is more useful than pure HTML for webloggers because by letting the program impose a structure on the narrative, the blog allows authors to focus on their writing instead.
• The iPod did well because the designer was bold enough to leave features out.

Luckily for JavaScript, implementations such as Rhino and JScript leverage off the OO libraries of JVM and CLR respectively.

These implementations hold great potential.

They benefit from having some structure because the class libraries are object oriented (hence have objects whose behaviour are easier to figure out), but offer the advantage of prototypes, where behavior can be modified without having to subclass.

This would hit the sweet spot of making composite applications.