From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.eiffel:83 comp.lang.ada:2162 comp.lang.c++:2769 comp.software-eng:1251 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!ucsbcsl!eiffel!bertrand From: bertrand@eiffel.UUCP (Bertrand Meyer) Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++,comp.software-eng Subject: Flakiness Message-ID: <115@eiffel.UUCP> Date: 9 Mar 89 22:58:56 GMT Organization: Interactive Software Engineering, Santa Barbara CA List-Id: Some quotations from earlier postings: From <4571@hubcap.UUCP>, billwolf@hubcap.clemson.edu (William T. Wolfe): > Meyer's book comes bound up with a rather flaky > programming language [Eiffel]. This inevitably prompted requests for clarifications: From <517@maxim.ERBE.SE>, prc@maxim.ERBE.SE (Robert Claeson): > Can you please elaborate on that? I'm sure there are quite a few people > around who wants to know in what ways Eiffel is flaky. From <9443@megaron.arizona.edu>, mike@arizona.edu (Mike Coffin): > Do you mean that the language design is flakey, or that an > implementation is flakey? If the former, what is flakey about it? Response from the original poster, W. T. Wolfe, from <4574@hubcap.UUCP>: > I stand by my statement regarding Eiffel's flakiness. Further response to new requests for clarification: > I don't have the time to get into a Eiffel war at the moment, > but I'll be happy to go into detail around May 20th if anyone > is still interested. Comment from <45492@linus.UUCP>, sdl@linus.UUCP (Steven D. Litvintchouk): > From what I was able to gather at OOPSLA '88, the current Eiffel > *implementations* are indeed flaky, but no more so than was any Ada > compiler developed prior to 1985. > I am extremely interested in finding out whether Eiffel compilers do a > better job compiling Eiffel generics, than Ada compilers do compiling > Ada generics. I remain disappointed in how poorly Ada generics are > implemented by some Ada compilers. Mr. Wolfe is tough on us. Do we really have to wait until May 20th to learn why Eiffel is flaky? Please! How I am expected to sleep at nights in March and in April? With respect to implementations, my (obviously biased) view is that the basic implementation of Eiffel is sound and robust. It has been used to produce software systems totalling hundreds of thousands of lines at many different installations. (I don't know if that was the case with Ada implementations before 1985.) This is not too say that the implementation is perfect, far from it. Examples of areas where improvements are needed are syntactical error messages, support for repeated inheritance, size of the generated code. The forthcoming 2.2 release (April) addresses these. Also, parts of the environment other than the implementation proper have left much to be desired; this was especially true of the graphics library and tools in release 2.1, partly by our fault, partly because of X windows problems. This has been corrected for 2.2 and the graphics will be at the same level of robustness as the rest of the environment, in particular the basic implementation, the automatic recompilation facilities, the documentation tools etc. The latter are, I believe, of industrial quality; I am sure Eiffel users will intervene if they think this is an exaggerated claim. The comments to which Mr. Litvintchouk refers were made (I believe) not at OOPSLA '88 but at the Eiffel User's Conference, just before OOPSLA. They had to do with cases in which apparently simple modifications lead to too much recompilation. These are not so much Eiffel problems (although I hope solutions may be found within the environment itself) as problems that inevitably arise when reusability is put into practice on a broad scale, with many people working on shared libraries. To enable reusable software construction, three facilities are essential: - multiple inheritance - generics - an automatic compilation mechanism No commonly available object-oriented system (excluding Lisp extensions and research tools) offers any of these facilities. Eiffel offers *all* three. So it is not surprising that the problems mentioned should have been evidenced in Eiffel first. They can be avoided altogether if proper discipline is applied. With respect to the implementation of generics, there is no significant problem that I know of. Genericity is constantly used in Eiffel (beginning with the basic library), so Eiffel users would be in a rather hopeless situation if this did not work. (I talked to Mr. Litvintchouk and he mentioned that the situation in Ada may be worse than what his message suggested: one member of the original Ada design team told him that no current compiler supports generics well. This is very different from the Eiffel situation.) After I wrote the above I thought again about the flakiness of the language itself. I realized that I didn't really know what ``flaky'' means, so I turned to my big ``Webster's Unabridged Collegiate Dictionary''. The definition for ``flaky'' does not list any really negative meanings; it includes ``cleaving off in layers'', which might perhaps apply to Eiffel, but also a meaning qualified as ``Slang'', namely very eccentric or unconventional. I have absolutely no quarrel with Eiffel being thus characterized, and I now realize that Mr. Wolfe actually meant to flatter us. For this I am grateful to him - and I can sleep again. -- Bertrand Meyer bertrand@eiffel.com