Journal TrixX's Journal: Quality, Re-usability, Standards and Implementations 2
Quality?
For a long time, the Holy Grail of Software Quality has been sought. A lot of efforts have been made, but we have no satisfying solution to date; Brooks has even stated (and has a large following) that there is no silver bullet, which is usually misunderstood as "there is no solution" instead of it's real meaning of "the solution involves a lot of coordinated efforts from different viewpoints, not just a single tool/method".
Some people (one of them B. Meyer) have proposed some necessary (but not sufficient) conditions for quality. The most prominent of them is perhaps known as re-usability, defined by Google as "The ability of a package or subprogram to be used again without modification as a building block in a different program from the one it was originally written for.".
Re-usability does not improve quality per se. This is quite obvious but most people overlook the real reason that makes re-usability important for quality: work made on improving the quality of a reusable component, improves all systems using that component.
A sad story
Meyer designed Eiffel in 1985 with that in mind. All the OO mechanisms, the way that inheritance is shaped in Eiffel, software contracts, the whole design shows that it was made caring for re-usability. A lot. And that was a Good Thing (TM).
And then, in 1986, the Eiffel design was made implementation by Meyer's company, ISE. And that was the first mistake because, although the language was designed to reuse components between programs, you were not able to use that software without depending on ISE. There was no Eiffel standard.
Some efforts were made, not much later. Meyer wrote a very clear language specification, in the form of a Book, "Eiffel: The Language". And NICE was founded to standardize the library. Several implementations appeared. All should have been happy at this time, shouldn't it? Not so much. It took until 1995 for NICE to have their first standard library (ELKS95). And the standard was incredibly small; it had basic stuff like INTEGER, STRING and ARRAY, but not much more. Every compiler, of course, included a lot more than that (so you could use them to write real software). But given the lack of a standard, all these libraries were incompatible (besides, usually not 100% ELKS95 compliant).
And thus, the language designed for re-usability, ended up being implemented by several incompatible implementations; software developed on one of them didn't work on the others. The choice was to write software only using ELKS, and ELKS based libraries, and ignore (i.e., not reuse) anything else (which included most libraries included with compilers and most third party libraries). A lot of Eiffel software is written from scratch today, instead of reusing, so a lot of people expect a sad end of the story today. NICE hasn't done too much since then; 6 year later they released ELKS2001 which was just some minor changes on existing classes of ELKS95.
Despite some efforts to bridge this problem (most notably the GOBO project, which maintains a set of useful, compiler independent set of libraries bigger than ELKS), the problem stays today... or is just worse.
In 2003 the standardization process was put in the hands of ECMA. The standard is moving forward quickly but looks quite different from the language compiled by today compilers. In fact, a pure ECMA compliant compiler won't compile most of the code you can find today. Some backward compatibility may be added, but not all of the new features lend themselves to backward compatibility. So, if any compiler goes the ECMA way, reuse (even between versions of the new compiler) will be almost impossible (even assuming that introduced language design bugs are removed). And so, some compiler writers (like the Open source SmartEiffel) have said publicly that they're forking and won't follow ECMA. It's hard to know what ISE will say, but given that it has clients to support, I can guess it will be conservative.
To complicate things even more, in 2004, the SmartEiffel team released the 2.0 version of their compiler. It introduces a lot of new changes, restrictions, enough to make most of the code that worked with 1.1 uncompilable. 2.0 was a disaster; in 2.1 they added some things that helped compatibility (while breaking others), and for the not yet released 2.2, they are adding some compatibility fixes.
The Eiffel community is getting split. And getting tired of all the bickering and forking and incompatibilities and lousy standard. And they are stopping using Eiffel: the incompatibilities between implementations and standards hamper any attempt of reuse, and thus software quality. Eiffel was designed to achieve software quality, but the design is not being enough. So, the different players today, all of them pulling in well-intentioned different directions are killing a beatiful language.
I'm not saying "Eiffel is Dying" (you may have listened the same about Apple or BSD). I'm saying "Eiffel is being killed. Stop it."
So what do we do now?
I don't think a company (ISE or any other) will have the strength to survive the uncertainty around Eiffel today. They will be tied between the tension of keeping compatibility for their customers, and supporting the standard, and they'll lose customers both ways.
I think the only way out is a strong Open source community around Eiffel. A large united community is more or less independent of being pressed by customers, knows how to adopt good standards and reject bad ones and keeps high the availability of library goodies ("comes with batteries included", they say in the Python community). However that requires good open source tools. The obvious choice is the SmartEiffel compiler, but they keep braking backwards compatibility so the availability of libraries is decreasing instead of increasing, and a lot of developers are tired from trying to keep up.
Another Free choice is Visual Eiffel (they opensourced their command line compiler recently); but it has almost no community behind. SmartEiffel has the "monopoly" on Free compilers, in the sense that it is good enough to not have too much competition, but OTOH is not good enough to join the community together.
The only hope now, is perhaps a good open source compiler, with an open development process and with an effort for compatibility, and an effort into trying to make reuse possible for already written libraries. That could get together the existing community. Perhaps that's enough to start growing again and keep the language alive. And perhaps we will have an Eiffel implementation, a standard, reusability, and quality
I hope.
It's evolution, baby (Score:1)
From what I gather from the Java community, the problems you are describing are solved through Sun keeping an iron hand over the language. Though they have bee
Re:It's evolution, baby (Score:2)
Meyer has not been working at ISE for a long time. Perhaps he still is an owner/shareholder/whatever, but his current job is academic at ETH Zürich [inf.ethz.ch].
The problem at ISE is that they're not actually in the business of selling compilers/IDEs, but selling support for current customers. Telling their current customers "We're going to support ECMA" is telling them "We're not going to mantain the compiler you're now using, so you'll get stagnant or will have to put a lot of money in upgrading all your softw