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.
It was these three points that the workshop sought to address. The workshop report is here and the interim community wiki is here.
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.
Resources:
wolandscat
Woland's cat 
It’s worth noting that the latest iteration of C# includes code contract support via extensions to the Diagnostics namespace of the framework (http://msdn.microsoft.com/en-us/library/dd264808.aspx), something I see as a discriminating feature of Eiffel the language. And such continuous iterations of the language driven by business needs are really helping it keep its head above water for all but esoteric uses.
Having not used Eiffel much though I get a feeling probably it’s better for formal methods programming. Nothing in the .NET framework or C# forces such good behaviour from the programmer.
The two biggest single reasons for Eiffel’s ‘non-assimilation’ are price and platform. Eiffel is expensive, with no established (not enough zeros in the count) ‘community’ to offset that (although community does not outweigh price by a long shot). And as long as it won’t run on the JVM, Eiffel simply isn’t useful enough to the broader programming community to justify bucking the stream (and cost) issues to champion its adoption. And I say this as someone who has been following Eiffel and waiting for it to grow up (become generally useful) for most of its history.
After those two issues, libraries are also definitely lacking. And the author misses the fact that Java has been steadily adapting to and adopting (if sometimes slowly) to include the concepts introduced by all of the alternative tools and languages he mentioned in his article.
As for the issue of the JVM maintaining backward compatibility: the Java community is addressing this as well. And I (and lots of other programmers) actually like the idea that I won’t get called in the middle of the night because someone upgraded the JVM on the server. While it has its drawbacks, this is a net benefit, not an (immediate) problem.
Last, the historical Eiffel myopia regarding single inheritance (and interfaces) vs. multiple inheritance hasn’t done it much good, either. Consider Go, which is abandoning formal classes entirely in favor of interfaces. I’m not sure how that will work out, but it is an interesting development.
My observation is that it is Eiffel that has been slow to adapt and adopt language and environmental changes, and this has been unfortunate and disappointing to watch. And while I firmly agree that Mr. Meyer and Co. have every right to compensation for their excellent work, it appears also to be true that their marketing strategy for the Eiffel language has been counter-productive in a world where their leading competitors are available for free from the internet, and the their competing communities of developers share their work and band together from all parts of the globe and the general programming community to make it better.
Does this help?
I can’t disagree with anything much here. I do think Java has been very slow. We have devs who use Java and C#, and the story is always the same from them – C# is a much better language today (.Net 4.x) but Java has way better components available. You can’t win!
It will be interesting to see what happens in the next 5 years with all these new languages.
Expensive is right. It stands now at $7500/seat and almost beyond reason in any pocketbook. I am highly disappointed.
Well their business model is a problem now. They have long-term existing customers paying that, with a complete inability to get new customers at that price. THey need to be charging IntelliJ or Oxygen prices…