burtonl@cognos.UUCP (Burton Leathers) (04/06/90)
Reply to Bob Weiner's query. It was asked what, if anything, Cognos is doing with Eiffel at the present time. Last July Cognos ceased working with Eiffel as a development language. There were a number of reasons for this action but the ones which are relevant to this news group are the technical ones. The main reason Eiffel was dropped because of problems with the size and speed of the executables which were generated using Eiffel. There are a number of reasons for the problems which we encountered, some of which have been addressed in Release 2.2 but some of which remain. The biggest problem was that the table which was used to implement dynamic dispatching was quadratic in the number of classes in the system. In a system with a small (<50) number of classes, this cost is barely visible. In a large system (~1000 classes) such as we had, the table sizes were show stoppers. We did implement a technique, since adopted by ISE, to reduce the table size by over 90% but at this point other tables became the problem. We also encountered serious execution time problems with the cost of function calls. The ISE stack frame and exception handling setup was quite expensive. Again we made local changes to the compiler to reduce the cost significantly but much more radical surgery would have been required to bring execution times into line with our requirements. We found that Eiffel was not a particularly tractable tool in a large, multi-developer environment. The cost of compiles was extremely high. This arose from two sources. The Eiffel to C generator was implemented by brute force methods. It is easy to accept this approach in a first implementation in which the primary concerns are correctness and robustness. However, for production work, we could not tolerate the speed penalty implied by the repeated reparsing of the source. There is a very real need to reduce substantially the I/O the compiler performs. We estimate it would be possible to obtain a significant speedup simply by coalescing most of files in the .E/ files and by eliminating the character conversions. We found that the tight coupling of the .e and .E/ files made it essentially impossible to share classes between products, between versions of the system destined for different platforms and between baselevels and test versions. The only way we could share (reuse) classes was to copy source -- a very ugly solution which created endless other source control problems. The most bizarre problem we encountered was that it was entirely too easy to create situations in which compiles were non-terminating. Because Eiffel has to assure system consistency at compile time -- the linker is too dumb to do it -- it is possible to have two developers change classes in such a way that they have mutually inconsistent systems. The compiler will then get itself into a situation of changing and rechanging the compiled version of a class used in both systems and the two compiles run forever. While Eiffel was dropped for negative reasons, positive aspects cause us to continue to retain interest in the language. Eiffel was picked in part because it promised portability. This was a major win on our project and we were able to port an enormous quantity of code (as C) without any more work than a recompilation on the new platform. We found that once programmers had made the paradigm shift from C to Eiffel they were more productive and would have been yet more productive had we had a decent Browser and a proper source level debugger. There were several times when large parts of the system had to undergo radical restructuring and the OOP properties -- especially encapsulation -- made this fast, practical and safe. In brief, we liked the language as a language but the implementation was not strong enough. Were the problems we have encountered to be resolved we would be only to pleased to take another shot at using Eiffel. As matters stand, we are revisiting the whole area of OOP languages. There is a strong desire to return to using OOP because of the positive aspects of our experience with Eiffel. However, having had a painful encounter once, there is a reluctance to proceed without an assurance that we will not again have the problems we encountered. The prospect of an Eiffel consortium which would open up the field for the public standardization of Eiffel with a consequent opportunity for alternate offerings is most welcome. A broader application of forces and a synergy of efforts could do a great deal to strengthen Eiffel as a development tool. Burton Leathers, Manager OO Programming Systems Evaluation Cognos Incorporated -- Burton Leathers 3755 Riverside Dr. decvax!utzoo!dciem! Cognos Incorporated P.O. Box 9707 nrcaer!cognos!burtonl (613) 738-1440 Ottawa, Ontario CANADA K1G 3N3