On 27 June, I ran a workshop at TOOLS 2011 in Zurich, entitled ‘Creating the new Eiffel Technology Community’. I did this at the invitation of Bertrand Meyer, the inventor of Eiffel and also the TOOLS conference programme chair.
I had several reasons for making this effort. The proximate one was being inspired by what I saw at FOSE 2010, a conference on software engineering, also in Zurich in November 2010 (blog post). Secondly, I have been using Eiffel since about 1990, in some form or other, due to hearing Bertrand speak at a software conference in Sydney. My interest then was software quality: reliability, comprehensiveness, extensibility and so on, and it was not an academic interest. At the time I worked in distributed real-time systems and was looking for languages that could go beyond C and the emerging C++ – languages that could safely be used for systems that control nuclear power stations.
Since then I have been involved in writing a number of things in Eiffel, including: an Eiffel binding for the Matisse Object database, a rule-based investment ‘compliance’ system (using the Gobo compiler tools and EiffelNet socket-based communication layer), and the Archetype compiler for openEHR, used in the ADL Workbench and Archetype Editor tools.
Now you might start wondering, why did I not personally move to languages like C# and Java, along with the rest of industry (as used by my company Ocean Informatics, for example)? The answer is twofold. Firstly, I don’t have time to write much software, I mainly work on architecture, standards and specifications (outside of other business-related activities). Secondly, for the software I still actively maintain – the Archetype compiler and workbench tool, contains relatively difficult logic (it implements a kind of object modelling stack) – neither Java nor C# hold any attraction. With neither language could I hope to work as efficiently as with Eiffel. This is not because I don’t know these languages. I programmed major software in C for about a decade, and keep up with the developments in post-C languages like Java and C#. The reason is that everytime I consider jumping from Eiffel into either language, the job of writing a compiler and all its attendant tool logic looks intolerably horrible. Neither language has anything like the power of Eiffel (although C# is a lot more attractive than Java today, due to not being strangled by the need for JVM backward-compatibility).
Ok you say, if Eiffel is so good, how come it is not ruling the world? Well the history of uptake of computing languages is somewhat complex, with popularity often not relying on technical aspects, but on political and commercial needs. My view of history, starting at a certain point is:
- everyone was using C for mainstream software (if they weren’t, they worked for the military or were at university having fun 😉
- we needed object-orientation, especially when all those nice diagramming books by Booch, Rumbaugh, Coad, Martin etc came out
- C++ and Objective C and Eiffel appeared, Smalltalk was already around (as were others such as Modula3)
- C++ was way too complex and had no garbage collection and broken multiple inheritance; only highly paid telecoms software engineers could use it properly
- Objective C was nice but only used in Apple/Next land, so the rest of us didn’t touch it
- Smalltalk had no static typing (noone in realtime was going to touch that!) and was probably slow
- Eiffel suffered from weak tools: because it was so sophisticated, the tools were significantly harder to write
- after some years of this, there was still no ‘sweet spot’ OO software development language available for the masses
- Sun brought out Java, with working garbage collection, simplified object semantics, none of the C++ pain, reasonable C-like typing, and with a great new idea called the Java Virtual machine, meaning it could be run anywhere.
- Microsoft thought about being in the Java camp for about 18 seconds and then brought out C#, a language copy, but also its own major computing framework, .Net.
- Both of these developments gave the mainstream a sweet spot language, and huge advantages in terms of a) deployment and b) large component assembly – Java via a huge open source community (particularly Eclipse, JBoss etc) and C# by being connected to all Microsoft’s tools, SQL Server, and so on.
For some time it looked like Java and C# would be the end of the mainstream language wars. But interestingly, they are not. Their real importance was as the harbinger of a new kind of development approach – technology that includes two key things over and above a language and IDE:
- the ability to assemble large components quickly
- ease of deployment onto diverse platforms and machine types
I.e. it is no longer about ‘language’, but about ‘system building and deployment’. This is borne out by more recent developments such as the emergence of Ruby on Rails, Python, and Scala, which will probably take over from the now very dated Java language. Apparently, new languages are not a blocker for moving to new development technology.
Where does Eiffel fit in all of this? It was routinely mentioned in every major object technology book of the 1990s, along with C++, Smalltalk and Ada. Bertrand Meyer’s book ‘Object-oriented Software Construction 2nd Ed.‘ remains the bible of object-orientation (despite its failure to use C# or Java syntax!), and his latest book, ‘Touch of Class‘, using Eiffel, makes me wish I could learn programming all over again. So what happened to Eiffel? The problem as I see it, is that it could not compete with the heavily marketed languages of C# and Java, and as it did not provide either its own deployment platform nor easy large system building capability, a la Ruby on Rails, Python/Zope/Plone and the Java server component world, it could not win mainstream support.
This is a pity, because Eiffel is a superior language in every respect, and by a country mile. But the real question is: does this matter? In my introduction presentation to the workshop, I argue that it does. As it happens, Bertrand Meyer, the people at Eiffel Software, and many others have been beavering away for the last decade on features such as agents (delegates), Void-safety and concurrent programming that take the language onto a different planet compared with the mainstream (which still has not caught up with the basics of a proper type system, multiple inheritance that works, or design by contract). Today it is simply quicker and easier to write quality code in Eiffel than any other language I can think of. If I was looking for alternatives, it would be among the Erlangs and Haskells, not in today’s mainstream languages.
Eiffel’s weak point has been the lack of ease of both large component integration and deployment options. A third feature lacking has been a lively, well organised open source community, like the Eclipse, LAMP and Ruby communities.
A lot can be learned from these other communities both about the technological aspects, and also how to run a community. In particular, we have to think the way young people think. Young developers are now used to being able to work in integrated development environments like Github, SourceForge, Atlassian etc, and they expect to be able to connect a database or GUI to core code in a matter of days if not hours.
I have high hopes that we can bring a lot of this to Eiffel. The biggest technical challenge will be deployment options – which probably include improving the connections to the .Net and JVM platforms, but might also include something new (and fun;-). The main challenge may be the social one: getting all of the existing ‘community’, disparate as it is, into some sort of coherent shape.
Watch this space.
- Eiffel on wikipedia
- ‘Object-oriented Software Construction 2nd Ed.
- SCOOP – concurrent programming in Eiffel