[T]he story told in this article is
one of glaring, unremitted and probably
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.
I imagine that this document was written to a target audience, propbably so as to
satify some funder's requirement, e.g. as 'post-mortem' for his ERC grants. Audiences have expectations as to what can and cannot be said. Funding organisations want/need success stories. Honesty is
not always appropriate see e.g. yesterday's . Honesty needs
'padding'. Meyer had numerous students, and his last sentence makes a
statement about their professional work too.
Well, I think the phrase "glaring, unremitted and probably definitive failure" is not one of modest honesty, and if he would have wanted to be politically correct, he could have definitely phrased it differently. (Just trying to look at this objectively).
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 . Automating formal verification so
that normal programmers can use it routinely in mainstream programming is an
unsolved problem in December 2017.
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.
I was lucky enough to be able to attend the LASER Summer School on Software Engineering for Robotics this year, which was a nice experience and I'm really grateful for Bertrand Meyer for organizing it. The LASER Summer School in 2018 will be about cryptocurrencies, so if anyone is interested in that you should certainly check out http://www.laser-foundation.org