OO, Lisp and startups (like JackBe)
Some comments on my previous post were about OO and Lisp. I think that we should accurately understand (or at least be aware of them) the OO-features that are implemented in CLOS. Also I want to share the vision of Bertrand Meyer (the creator of the Eiffel programming language) about the object orientation of Lisp.
As long as I understand, the main CLOS features are:
- Built-in classes integrated with type system.
- New classes definable, also integrated with types.
- Classes may inherit from multiple ancestors.
- Class variables as well as instance variables.
- Automatic combination of four method types.
- Methods may specialise on any number of arguments.
In his classic Object Oriented Software Construction (2nd edition), Bertrand Meyer writes:
Like many other pre-O-O languages, Lisp has served as the basis for several object oriented extensions; in fact many of the earliest O-O languages after Simula and Smalltalk were Lisp-based or Lisp-like. This is not surprising, since Lisp and its implementations have for many years offered mechanisms that directly help the implementation of object-oriented concepts, and have taken much longer to find their way into mainstream languages and their environments:
- A highly dynamic approach to the creation of objects.
- Automatic memory management with garbage collection.
- Ready implementation of tree-like data structures.
- Rich development environments, such as Interlisp in the seventies and its predecessors in the previous decade.
- Run-time selection of operations, facilitating the implementation of dynamic binding.
The conceptual distance to O-O concepts is, then, shorter if you start from Lisp than if you start from C, Pascal or Ada, so that the term “hybrid” commonly used for O-O extensions of these languages, such as the C-based hybrids which we will review in the next sections, is less appropriate for extensions of Lisp.
Artificial Intelligence applications, the prime application of Lisp and Lisp-like languages, have found in O-O concepts the benefits of flexibility and scalability. They have taken advantage of Lisp’s uniform representation for programs and data to extend the object-oriented paradigm with notions such as “meta-object protocol” and “computational reflection” which apply some of the O-O principles not just to the description of run-time structures (objects) but also to the software structure itself (classes), generalizing the Smalltalk concept of metaclass and continuing the Lisp tradition of self-modifying software. For most developers, however, these concepts are a little far-off, and they do not blend too well with the software engineering emphasis on a strict separation between the static and dynamic pictures.
Three main contenders were vying for attention in the world of O-O Lisp in the eighties: Loops, developed at Xerox, initially for the Interlisp environment; Flavors, developed at MIT, available on several Lisp-oriented architectures; Ceyx, developed at INRIA. Loops introduced the interesting concept of “data-oriented programming”, whereby you may attach a routine to a data item (such as an attribute). Execution of the routine will be triggered not only by an explicit call, but also whenever the item is accessed or modified. This opens the way to event-driven computation, a further step towards decentralizing software architectures.
The unification of the various approaches came with the Common Lisp Object System or CLOS (pronounced C-Los by most people), an extension of Common Lisp which was the first object-oriented language to have an ANSI standard.
So, I will never agree on minimizing the importance object oriented paradigm has on both Computer Science and Software Engineering. And as a final thought on the previous discussion over OO and Lisp, please re-read the paragraph on the previous text that starts as “The conceptual distance to O-O concepts is…“, because it makes clear that those two features Common Lisp mixes (program/data in a single structure and OO) are non-exclusive and they can even be related in some implementation.
Finally, I want to emphasize that Common Lisp offers benefits of both worlds: first, data and program itself as a single structure and second, the marvels of object orientation.
And as I stated today after arguing about Lisp usage in JackBe and learned from Paul Graham: if you are a startup you MUST do things in other, but more clever, way than competition does, and of course, a startup needs elite programmers who could build and maintain those creations. As he stated in his Beating the Averages article:
Robert and I both knew Lisp well, and we couldn’t see any reason not to trust our instincts and go with Lisp. We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn’t mean anything. If you chose technology that way, you’d be running Windows. When you choose technology, you have to ignore what other people are doing, and consider only what will work the best.
This is especially true in a startup. In a big company, you can do what all the other big companies are doing. But a startup can’t do what all the other startups do. I don’t think a lot of people realize this, even in startups.
The average big company grows at about ten percent a year. So if you’re running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company– that is, to grow about ten percent a year.
The same thing will happen if you’re running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you’ll go out of business. The survival rate for startups is way less than fifty percent. So if you’re running a startup, you had better be doing something odd. If not, you’re in trouble.
Enough for today.
