Richard P. Gabriel has a large set of essays online dealing with some important issues in designing software which is both usable and evolvable. He wrote (a while back, though the article isn’t dated an article about the MIT/Stanford “The Right Thing” style of design in Lisp (and, for example, the Incompatible Timesharing System, developed by MIT AI Lab hackers for the PDP mainframes) and the “Worse is Better” approach of Unix and the C programming language.
The software I produced in the course of my PhD was written in the Eiffel language, which is perhaps a perfect example of the flaws in the “The Right Thing” approach. Eiffel is well designed, its features are well integrated and considerable thought has been put into how those features interact and add up to the complete language by its designer, Bertrand Meyer.
Eiffel is also undeniably flawed. In its traditional incarnations (for example ISE Eiffel, by Meyer’s own company, and SmartEiffel, a Free Software Eiffel compiler) it demonstrates very well that “pure” object oriented code (in the sense that all data types, including for example number types, are instances of some class) with automatic memory management can be compiled to highly efficient executable code. One of the tools it uses to achieve this, however, is whole system analysis, and the result of this, as Clemens Szyperski has argued (leastways I think it was that paper, and I’m not going to read it again now to check), it to block “independent extensibility”.
Or, in the case of Eiffel, any extensibility at all after compilation. Which is ironic, considering that Meyer trumpets Eiffel as a language for component combination: this only makes sense under the view of components as lumps of software which must be glued together into closed assemblies before use, it cannot admit dynamically loadable components. ISE did provide a very limited dynamic loading facility for Eiffel some time ago, but further inquiry revealed that it was only available for the Solaris operating system on Sun workstations. It also worked by allowing the system programmer to explicitly block system optimisations in certain areas where loadable modules might be attached.
This limitation may be removed by using ISE’s new version of Eiffel which targets Microsoft’s .NET Common Language Runtime, which also has the advantage of allowing such “independent” extensions to be created in any of the programming languages which can target .NET (although it has been argued that all of these are necessarily actually the same language, as enforced by the .NET object model, differing only in syntax. To do so (and I haven’t tested this) I can only imagine that the resulting code takes a performance hit from the fact that, if it is impossible to say at compile time how your code will be used in the future, it is impossible to apply the sort of code-rewriting optimisations which result from whole system analysis at all, never mind in specific areas.
In his opening remarks for a debate with the motion “Objects Have Failed”, Gabriel argues powerfully for a more diverse ecosystem, in which world views other than that of object orientation are admitted. Having spent considerable time jumping through hoops to express a model of models in Eiffel which is quite different from the underlying object oriented model of the language, I can only agree. He also here touches on another major flaw in Eiffel, and in most popular languages, which is that they have abandoned the dynamic nature (which permits, ultimately, self modifying programs) which was a central concept of the early developement of the object oriented approach.
Comments