Fourteen Years of Software Engineering at ETH Zurich

“”” Still, one should not lie. The outcomes that matter in research are not numerous publications, best-paper awards, completed PhD theses, keynote invitations, soft- ware tools, citations and other measurable signs of progress. I was after real success, in the sense of changing the way the IT industry develops software. That was the only justification for putting in parentheses my career as a technology entrepreneur. When you have an ambitious goal, you should be judged by that goal. Such absurd pieties as “it’s the journey that matters” or “what’s important is to participate” (by, of all people, Coubertin, founder of modern Olympics) are even more wrong in research than anywhere else. Only the result counts. By that standard, the story told in this article is one of glaring, unremitted and probably definitive failure. “””

Reports of success in those areas combined with what's in this document might allow people to develop hybrid approaches that get stuff done along both axises. As partial confirmation, we've already seen some of the same types of tooling that Eiffel has develop in .NET and Java spaces. Companies pay a lot of money for them, too. Still potential to repeat some of ETH's success with integrated tooling for other mainstream languages mixing tech that benefits various aspects of the software lifecycle. The releases could be a mix of proprietary tools that generate funding plus FOSS components that keep a strong ecosystem of contributors.

Language choice is mostly dependent of social factors that can be summarised as "network effect". In PLs that manifests itself primarily through a lack of mature and numerous libraries.

Eiffel had additional technical flaws:

- Subtyping was wrong.

- Handling of concurrency was wrong, in the sense that almost all concurrency was hidden, instead of exposed. Eiffel was an anti-Erlang in this regard.

- A lot of modern PL features were missing, e.g. pattern matching, first-class higher-order functions.

- The single most distinctive of Eiffel's features, built-in support for assertions, was not supported by good-enough tools.

I would argue that the last point is still the case today for all formal verification, see e.g. Microsoft's Dafny [1]. Automating formal verification so that normal programmers can use it routinely in mainstream programming is an unsolved problem in December 2017.

[1] https://github.com/Microsoft/dafny

Think Rational Rose, Together, Enterprise Architect, Visual Studio Ultimate kind of prices.

Eiffel is a great language, proper OOP, value types, generics, contracts, MI, non nullable types, nice IDE, JIT and AOT compilation via native or C/C++ compilers.

But the price made it out of reach for most developers and the open source variants were a poor replication of the whole experience.

Nowdays there is a free license for open source projects, but it is too late for widespread adoption.