dmg@ssc-vax.UUCP (David Geary) (06/01/89)
I've been programming in C for about 5 years, and just recently started using C++. I would like to start a discussion of Eiffel vs. C++. I understand that both languages use C as a base language, and that both implement OOP features, and it seems as though the two have much more in common, aside from syntactic differences, than they have differences. Note that I'd like the discussion to center around version 2.0 of C++ vs. the most current version of Eiffel. I am aware of the fact that Eiffel has a robust library of base classes, but I would like to see a discussion of language *features*. About the only difference that I can discern is the fact that Bertrand Meyer posts more often to comp.lang .eiffel than Bjarne Stroustrup posts to comp.lang.c++ ;-) ;-) -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ David Geary, Boeing Aerospace, Seattle ~ ~ "I wish I lived where it *only* rains 364 days a year" ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jima@hplsla.HP.COM (Jim Adcock) (06/03/89)
Well, I'm not an Eiffel programmer, but I have read the Eiffel book. I have heard rumers that there are a lot more problems in general with compilers for Eiffel than with compilers for C++. Perhaps someone can illuminate. > I've been programming in C for about 5 years, and > just recently started using C++. I would like to > start a discussion of Eiffel vs. C++. I understand > that both languages use C as a base language, and > that both implement OOP features, and it seems as > though the two have much more in common, aside from > syntactic differences, than they have differences. Both the only compiler for Eiffel and AT&T derived compiler use C as an intermediate code to compile to. This allows the actual machine code generation to be performed on a C compiler for a given machine. This is different than saying both use C as a base language. C++ syntax is based on C. Eiffel syntax looks Pascal-like -- at least to my eyes. So I'd say C++ is to C as Eiffel is to Pascal. I'd expect one's experience comparing Pascal to C would carry over in comparing Eiffel to C++. It appears [at least in reading the book] that Eiffel uses at least references to objects, if not handles, rather than C++'s concept of a "object" being the actual block of code. So I'd expect C++'s ability to make a object from other objects would be faster than Eiffel's approach [and Smalltalk's, and ObjC's, and ...] The Meyer book raises some interesting points about OOP, and I think it makes a good addition to one's OOP library, but I'd stay with programming in C++ -- if one has practical programming tasks to accomplish.
sarkela@eiffel.UUCP (John Sarkela) (06/03/89)
> I've been programming in C for about 5 years, and >just recently started using C++. I would like to >start a discussion of Eiffel vs. C++. I understand >that both languages use C as a base language, and >that both implement OOP features, and it seems as >though the two have much more in common, aside from >syntactic differences, than they have differences. First, consider the relative grammatical complexity of the languages. Eiffel is an LL(1) language, whereas net comments seem to suggest that C++ may not even be LALR(1). Much of the grammatical complexity of C++ seems to derive from its historical precedents. The simplicity of the Eiffel grammar has much to do with the fact that it does not attempt to be source compatible with prior languages. Eiffel, the language, is not C based. The relation which Eiffel shares with C is solely that of source language to target language. Second, consider some the features of C++ which Eiffel does not possess. Eiffel does not possess global variables. Eiffel does not possess pointers. The elimination of gratuitous pointer aliasing and extern'ed globals allows a smart compiler greater lattitude in generating optimized code. Third, consider features of Eiffel which C++ does not possess. One of the stronger motivations for using object oriented techniques, is to take advantage of sharing at least specifications and hopefully implementations. With untyped object languages such as Smalltalk this follows naturally. In the case of statically typed languages, however, the denotations for collection, aggregate, or container classes must either be duplicated for each contained type or or the container must be parameterized by the contained type. The Eiffel generic class parameter language construct directly addresses this issue. While ad hoc mechanisms may be used to rewrite nearly duplicate class declarations in a language which does not support genericity, IMHO it is perhaps better to put all type parameterizations within the scope of the language type system. Eiffel has included for some time multiple inheritance. At this point in time, I do not have access to a description of MI in C++. Given a familiarity with C, however, I expect that namespace traditions of C could make MI a subtle feature of C++ Rev. 2.0. Finally, consider one of my favorite uses of MI in Eiffel, the specification class. Given the ability to specify class invariants, and method pre and post conditions, one can write a specification class which fully qualifies the domains and ranges of all class methods. Eiffel provides language hooks which allow straight forward specification of these qualities independent of the implementation of the components. One thus may use multiple inheritance to provide both a "is-a" categorization of the refined class as well as the "code reuse" of implementation inheritance. I don't have C++ 2.0 documentation so I don't know the extent of exception support, nor do I know the rules for MI in C++, can anyone give a definitive explanation? BTW, can anyone clear up exactly how one specifies the input restrictions and legitimate outputs of library C++ components? Conclusion: Eiffel is a grammatically simpler language than C++. Eiffel does not have many language features that C++ inherited from C. Eiffel has language support for component specification and qualification. John Sarkela sarkela@eiffel.com
bertrand@eiffel.UUCP (Bertrand Meyer) (06/04/89)
From article <6590138@hplsla.HP.COM> by jima@hplsla.HP.COM (Jim Adcock): > > I have heard rumers [sic] that there are a lot more problems in general with > compilers for Eiffel than with compilers for C++. Perhaps someone can > illuminate. I'll be straightforward. We, the developers of Eiffel, are fed up with ``rumers'' and slander. That the proponents of C++ are desperate for technical arguments is understandable, but does not justify everything. -- Bertrand Meyer bertrand@eiffel.com
UH2@PSUVM.BITNET (Lee Sailer) (06/04/89)
While I agree with most of this comment, I want to clear up one possible small understanding. In article <148@eiffel.UUCP>, sarkela@eiffel.UUCP (John Sarkela) says: > >Eiffel does not possess pointers. The elimination of Lest programmers get the wrong idea, let me say that Eiffel DOES have a mechanism that allows things to point at one another. In C (and C++, I guess) a pointer might be better called an "address". C is famous for offering the programmers access to low level machine primitives such as memory addresses, as you all know. The probelm is that the compiler cannot possibly know what the programmer intends to do with the address, and thus cannot optimize well. The same argument has been made about strings---C does NOT have a string type. We fake it with pointers (addresses) and arrays (pointers 8-). In a language that does have a specific string data type, the compiler writer has a chance to do some optimization tricks otherwise not available. >gratuitous pointer aliasing and extern'ed globals allows a >smart compiler greater lattitude in generating optimized code. > >Third, consider features of Eiffel which C++ does not possess. >One of the stronger motivations for using object oriented >techniques, is to take advantage of sharing at least specifications >and hopefully implementations. With untyped object languages such >as Smalltalk this follows naturally. In the case of statically >typed languages, however, the denotations for collection, >aggregate, or container classes must either be duplicated for >each contained type or or the container must be parameterized >by the contained type. The Eiffel generic class parameter >language construct directly addresses this issue. While >ad hoc mechanisms may be used to rewrite nearly duplicate >class declarations in a language which does not support >genericity, IMHO it is perhaps better to put all type >parameterizations within the scope of the language type system. > >Eiffel has included for some time multiple inheritance. At >this point in time, I do not have access to a description >of MI in C++. Given a familiarity with C, however, I expect >that namespace traditions of C could make MI a subtle >feature of C++ Rev. 2.0. > >Finally, consider one of my favorite uses of MI in Eiffel, the >specification class. Given the ability to specify class invariants, >and method pre and post conditions, one can write a specification >class which fully qualifies the domains and ranges of all class >methods. Eiffel provides language hooks which allow straight forward >specification of these qualities independent of the implementation >of the components. One thus may use multiple inheritance to provide >both a "is-a" categorization of the refined class as well as the >"code reuse" of implementation inheritance. I don't have C++ >2.0 documentation so I don't know the extent of exception support, >nor do I know the rules for MI in C++, can anyone give a definitive >explanation? > >BTW, can anyone clear up exactly how one specifies the input restrictions >and legitimate outputs of library C++ components? > >Conclusion: Eiffel is a grammatically simpler language than C++. >Eiffel does not have many language features that C++ inherited from C. >Eiffel has language support for component specification and qualification. > > >John Sarkela sarkela@eiffel.com
sarima@gryphon.COM (Stan Friesen) (06/04/89)
In article <2689@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: > > I've been programming in C for about 5 years, and >just recently started using C++. I would like to >start a discussion of Eiffel vs. C++. I understand >that both languages use C as a base language, and >that both implement OOP features, and it seems as >though the two have much more in common, aside from >syntactic differences, than they have differences. > >... I may as well put in my two cents worth. My impression is that Eiffel is a "higher level" language than C++. That is Eiffel is a very strongly typed OOP language, with a very simple, limited implementation of objects, whilc C++ is a very flexible language that allows you to get into the guts of the system when you need to. Thus, as someone else stated, Eiffel feels like Pascal and C++ feels like C. Eiffel is very simple syntactically, at the cost of requiring you to do everything its way. In particular, except for the basic scalar types, *everything* is a class. There are no seperate derived types, such as pointers and arrays. A class instance is essentially always a pointer, but without the ability to do pointer arithmetic, or in fact anything except allocate, deallocate, and dereference. Thus it acts like a dynamically allocated instance of an object. (In fact this is what Meyer would call it, rather than a pointer). Because of this there are a number of things not possible in the language. For instance the standard library class ARRAY, used to make array objects via inheritence, had to be implemented in C and grafted into the language using the "foreign" language import capability. This limitation is not often important, since most of the common cases where going outside of Eiffel have been anticipated and included in the standard library. C++, on the other hand, is more complex because it allows you to decide how you want to implement something. It has built in all of the scalar and derived types from C, thus allowing direct manipulation of low-level implementation details when necessary. It still has all of the class features that facilitate OOP. It has dynamic allocation, when needed, and it allows run-time typing (using virtual functions). But if you don't need them you don't have to take them. Thus the trade-off is a simpler, easier to understand language versus one that gives you more control. > > About the only difference that I can discern is the >fact that Bertrand Meyer posts more often to comp.lang >.eiffel than Bjarne Stroustrup posts to comp.lang.c++ >;-) ;-) > Well, Bjarne Stroustrup used to post here occasionally, but he claims to be too busy now. So Andrew Koenig has taken over posting here for him. -- Sarima Cardolandion sarima@gryphon.CTS.COM aka Stanley Friesen rutgers!marque!gryphon!sarima Sherman Oaks, CA
johnson@p.cs.uiuc.edu (06/05/89)
My favorite language is Smalltalk. I also do a lot of C++ programming. I have never programmed in Eiffel, but I read the book. Eiffel is a much more elegant language than C++. C++ is more-or-less upward compatible with C, which is both its greatest strength and its greatest weakness. C programmers will find it easy to program in C++, though they might take a while to learn how to use it to best advantage. Since there are so many C programmers, this means that C++ has a tremendous marketing advantage. However, if you don't use C then you don't care about this feature. Instead, you will spend a lot of time wondering why C++ has this or that feature, with the answer invariably being for compatibility. Given the constraint of being an extension to C, I think that C++ is quite well designed. However, Eiffel does not have those constraints, and so had a blank slate to solve problems like generic classes, multiple inheritance, and exceptions. Thus, it is not surprising that it is quite a bit simpler and yet more powerful. The first versions of C++ (i.e. the ones we had 3 or 4 years ago) were fairly unreliable. However, the current C++ compilers are pretty good. I'm sure that the first versions of Eiffel were also buggy, but there has been plenty of time to improve it. Eiffel has satisfied users. I have not seen any decent benchmarks comparing the languages. As a compiler expert, I don't see any real reason why Eiffel should be more than 10% slower than C++, though of course I am assuming a reasonably good compiler. If you are not a C shop, or if you are unhappy with C, then I would recommend giving Eiffel a close look. By that I don't mean reading the book. Instead, buy a copy of the compiler and use it. That is the best way to learn about a language and to be certain of the reliability and speed of an implemantation. On the other hand, if your programmers know and love C then C++ is the best way to go. You can quickly get them to use the new compiler, though getting them to exploit all the power of object-oriented programming will endoubtedly take longer.
bertrand@eiffel.UUCP (Bertrand Meyer) (06/05/89)
From article <2689@ssc-vax.UUCP> by dmg@ssc-vax.UUCP (David Geary): > I would like to start a discussion of Eiffel vs. C++. [...] > About the only difference that I can discern is > [joke about compared newsgroup patterns]. Since we often get the question of Eiffel versus C++, Mr. Geary's initiative provides a welcome opportunity to clarify what I see as the major differences. I am the main designer of Eiffel, so the following discussion cannot claim to be that of an independent observer, although it is certainly honest, and technically correct to the best of my knowledge. In all likelihood, others will contribute different viewpoints. I certainly cannot claim to be a C++ expert. If I misrepresent C++ in any way, it will be by mistake, not design. Should this occur, someone will certainly correct the mistake, either by writing to me (in which case I will post the correction if it does turn out that I have written something wrong) or by posting directly. This response has three sections: general observations; technical differences; conceptual differences. I apologize for its length; there is really a lot to say. Also, there is little new in the material below, much of which may be found in previous publications about Eiffel; none of my previous publications, however, has studied Eiffel from the point of view of a comparison with C++. Although I believe that the Eiffel environment and tools and the standard Eiffel libraries provide some of the major arguments for Eiffel, I will (with two exceptions explained below) limit the discussion to the languages proper, so as to abide by Mr. Geary's request: > I am aware of the fact that Eiffel has a robust > library of base classes, but I would like to see > a discussion of language *features* 1 - GENERAL OBSERVATIONS ------------------------ Eiffel was designed in 1985, initially not as a language for the rest of the world, but as an internal tool for a development that Interactive Software Engineering started at that time. We would have preferred to use an existing language and environment, but an examination of possibilities, including C++, quickly showed that nothing was even close to the minimum required for developing software according to the modern principles that I (then still a professor at the University of California, Santa Barbara) was teaching to my students. I did not want to develop a split personality or to fall into the ``do as I say, not as I do'' syndrome. I am mentioning this because in a way we had an unfair advantage: when we started, C++ existed. Although we certainly did not imitate C++, its very existence was helpful because it showed clearly what we did *not* want Eiffel to be. In a similar vein, we also looked at Ada, although in this case the ratio of positive to negative influences was higher. Even though Ada is not an object-oriented language, its syntax conventions and its handling of elementary constructs (expressions, control structures etc.) definitely influenced the corresponding Eiffel constructs. (By the way, only three languages did exert a strong semantic influence on Eiffel. One was Simula 67; the other two were not programming languages but specification languages: Abrial's Z, in whose design I was somewhat involved around 1978-79, and my own M, a successor to Z and to this day an unfinished design. A less important influence was Alphard.) Finally I do not think that in the long term Eiffel is really ``competing'' with C++. They have almost nothing in common in their aim and spirit, as explained in the final section of this message. In my undoubtedly biased view, the real competitor to Eiffel is Ada. (``Competitor'' for me is a positive word. When you acknowledge a design as a competitor to yours, it implies respect.) Ada, as already mentioned, is not truly object-oriented, but its official charter (reliability, reusability, professional high-quality software development etc.) is very similar, on paper at least, to that of Eiffel. 2 - TECHNICAL DIFFERENCES ------------------------- Software structure Eiffel software is organized in autonomous software units (classes), meant to be compiled separately. There is no main program. This is what I believe should be the case in object-oriented programming. In contrast, I understand that C++ still follows the traditional C model. Quoting from Dr. Bjarne Stroustrup's ``The C++ Programming Language'' (Addison-Wesley, 1986), which seems to be the major reference on C++, page 22, lines 13-14: ``A C++ program typically consists of many source files, each containing a sequence of declarations of types, functions, variables, and constants''. This is very far from the object-oriented model of software decomposition. Furthermore, reports from actual users of C++ seem to indicate a heavy use of ``include files'', a technique which I don't fully understand in the C++ context, and which has no equivalent in Eiffel. Assertions A fundamental property of Eiffel software is that it may be equipped with assertions. Assertions are elements of formal specification that serve to characterize the semantics of classes and their routines independently of their implementation. Assertions include in particular routine preconditions (which must be satisfied when a routine is called), routine postconditions (ensured by the routine on exit) and class invariants (global consistency conditions applying to every instance of a class). Assertions are essential for documenting components. As a matter of fact, I do not understand how one can talk about the very idea of reusable software components without assertions. Using a hardware analogy, a software component without assertions is similar to, say, an amplifier without precondition (the acceptable input voltage), postcondition (the gain, expressed as acceptable ratio of output to input) and invariant (including for example the temperature limits expected and maintained by the amplifier). Yet of widely available programming languages, only Eiffel has these notions. (A system that does have assertions, and in fact ones that are more sophisticated than Eiffel's current ones, is David Luckham's Anna system, developed at Stanford on top of Ada. As far as I know, however, this is not a deliverable product.) Beyond their documentation uses, assertions, which optionally may be monitored at run-time, provide a remarkable debugging and testing aid. At the recent International Eiffel conference in Paris, one user organization (Cognos Inc.) reported that they no longer perform traditional unit testing, having replaced it by assertion monitoring. Exceptions Eiffel has exception handling. Its exception mechanism is original and I believe it is one of our major contributions, based on the theory of ``Programming by Contract''. As far as I know, there is no exception mechanism in C++. I believe that one cannot write serious software without having a way to recover cleanly from unexpected cases. Global variables Consistent with the absence of main program is the absence of global variables. Global variables are well known to be detrimental to modularity and more generally to quality. The Eiffel technique of ``once routines'' is used to ensure disciplined sharing between classes when needed. (See my column in the Journal of Object-Oriented Programming, vol. 1, no. 3, pages 73-77, ``Bidding Farewell to Globals''.) In contrast, C++ seems to support global variables in the C style. Genericity Eiffel classes may be generic, i.e. parameterized by types, as in LIST [T]. Here actual uses of the class may use any type (class) as actual generic parameter, as in my_list: LIST [TEXT_LINE] The genericity may be constrained, as in MATRIX [T -> NUMERIC], which specifies that actual generic parameters must be descendants, in the sense of inheritance, of class NUMERIC (equipped with the operations "+", "-", "*" etc.). Descendants of NUMERIC include (in version 2.2) predefined types such as INTEGER and REAL. The operations of NUMERIC are available, within the class, on any variable of type T - so that it can define, for example, routines for adding and multiplying matrices. Note that in this example MATRIX itself might inherit from NUMERIC. Nothing of the sort exists in C++. This means that generic structures must be simulated by forcing type conversions, or ``casts'', using low-level C techniques. This defeats any attempt at static typing. A paper was published not long ago about a proposal for class parameterization in C++. (Although the paper was published in a refereed journal, it regrettably did not mention any of the two object-oriented languages that offer such a facility: Eiffel and Trellis-Owl, the latter designed by Craig Schaffert and others from DEC). Since by all reliable accounts the inclusion of such a facility in any form accessible to C++ users is several years away, it cannot be considered in any serious discussion. On that kind of time scale one can promise anything. Dynamic binding Dynamic binding is the default mechanism for routine calls in Eiffel (achieved without any undue effect on performance). The default policy in C++ is static binding; dynamic binding is only applied to routines declared as ``virtual''. This may look like an acceptable requirement to impose on programmers but I believe it is not. The whole idea of inheritance is that you may reuse a class later on by writing a descendant and adapting it to new uses by overriding some of the routines of the original - within the original semantic constraints, as defined by assertions. This should be done without impacting the original, which may be used by many other ``client'' classes. (These concepts are explained in my book ``Object-Oriented Software Construction, Prentice-Hall, 1988, as the ``Open-Closed Principle'', section 2.3.) In such a case the designer of the original routine may have had no inkling whatsoever that the routine would ever be redefined and subjected to dynamic binding. This is incompatible with the requirement that the original designer should have declared the routine as virtual in the first place. Instead of forcing the programmer to take care of low-level optimizations, the Eiffel approach makes the compiler responsible for exploiting the performance of static over dynamic binding. The optimizer, working on a set of classes, generates code that applies static binding to any routine which warrants it (because it is never redefined). Performing tedious and potentially dangerous optimizations in a safe way should be the role of computers, not humans. In-line expansion In C++ as in Ada a routine may be declared as ``in-line'', meaning that calls will be expanded in-line to gain performance. No such mechanism is available in Eiffel. Contrary to what one might think at first sight, I believe this to be a serious advantage for Eiffel. As soon as a routine is declared as in-line, its usefulness is severely limited because it no longer is a normal routine that can be redefined and subjected to dynamic binding. The discussion of the previous paragraph applies even more strongly. In Eiffel, once again, the corresponding optimizations are performed by the compiler, not by the human user. The optimizer will automatically expand certain routines in-line based on systematic criteria beyond programmer control. One of the criteria is of course that the routine not be subject to redefinition and dynamic binding; the number of calls in the code is another. Again, this seems the safe and efficient approach. Computers can perform this kind of task both more efficiently and more safely than humans. Operator overloading The term ``operator overloading'' is not entirely adequate since the issue is whether functions may be assigned names that will be used in prefix or infix form in calling expressions. This is a syntactic, not a semantic issue; the more important form of overloading, the semantic one, is provided in the object-oriented context by redefinition and dynamic binding. C++ offers the possibility of using an operator (from a set of predefined ones) as function name; a similar possibility is offered in Eiffel 2.2, although it was not present in earlier releases. So the two languages are indeed comparable in this respect. Consistency of the type system Beginning with version 2.2, Eiffel has a fully consistent type system in which every type, including basic types such as INTEGER, REAL and so on, is defined by a class (using the multiple inheritance mechanism). This was made possible by the introduction of the notion of expanded class, of special BITS M classes (whose instances are bit strings of length M), and of infix/prefix operators as discussed above. This is achieved without any effect on the efficiency of dealing with simple values such as integers, characters and the like. The advantage is mainly a conceptual one - being able to work with a single set of concepts admitting few special cases. There doesn't seem to be anything similar in C++, which uses the C types as basis. Type checking Because of the absence of genericity and the presence of the full C type system with its casts and other unsafe mechanisms, C++ cannot be reasonably be called a statically typed language. In contrast, Eiffel was designed as fully typed. The present Eiffel compiler misses a small number of type violations (arising in particular from cases in which polymorphism enables a client to evade an export or redefinition constraint). These cases seldom arise in practice, which is not an excuse for not handling them properly. Even with the current implementation, however, Eiffel is incomparably more type-safe than C++ because of the presence of genericity, of the strict enforcement of type checks in assignments, and of the absence of any unsafe casts or conversions. Friend functions C++ has a notion of friend function which, as I understand it, makes it possible to define routines outside of the object-oriented framework. There is nothing equivalent in Eiffel. This facility is not missed; I would see its introduction as a dangerous violation of the object-oriented principles. Deferred classes An extremely important notion in Eiffel is that of deferred class, which describes a non-fully-implemented abstraction. Deferred classes are used to capture commonalities and are central to the object-oriented approach. Two aspects are particularly important: the ability to define a partially deferred class, which contains both implemented and non-implemented routines; and the ability to attach assertions to a deferred class and its deferred routines, and thus to specify the behavior of yet to be implemented software. C++ as described in published references does not appear to support a similar notion. I have heard, however, that the forthcoming version of C++ has a notion of abstract class, which is meant to play the same role. Perhaps someone will describe this facility in detail so that readers can judge. Multiple inheritance Multiple inheritance is fundamental in the Eiffel approach. We made every effort to handle it in a very clean way; name clashes, in particular, are treated in what I believe is the right way. (More precisely, I do not know of any satisfactory solution in any other language. This is a strong statement, and proponents of other languages are welcome to respond to the challenge.) The published references on C++ systems exclude multiple inheritance which, however, is rumored to be imminent. I must confess this is one aspect on which we, at Interactive Software Engineering, are rather touchy. The first time I personally heard about the ``imminence'' of multiple inheritance in C++ was November of 1986. Since then, that is to say for two years and a half, we have essentially been unable to use the presence of multiple inheritance as an argument for Eiffel - so successful have others been in persuading almost everyone that multiple inheritance in C++ was around the corner. Here I would like to appeal to developers of software tools and suggest a universal ethical rule: whenever you refer to a feature that is not yet available in the released distribution of your product, mention it unambiguously in every relevant publication, together with an estimated date of availability (to the public, not internally). The name for such a policy is simple: honesty. This being said, it is indeed possible that multiple inheritance will become available in C++ during my lifetime. It is not clear from what I have read and heard that the non-trivial problems of multiple inheritance, such as name clashes, have been properly addressed. (If I am wrong on this, please enlighten me.) Renaming Eiffel offers a powerful technique in connection with inheritance: renaming. A class can rename inherited routines and attributes (i.e. methods and attribute variables for those who prefer such terms). This is used for removing name clashes in multiple inheritance and also, perhaps even more importantly, to provide locally adapted terminology when you inherit the right features but under the wrong names. As discussed in my OOSC book referenced above (section 10.4.7) and in a JOOP column (Vol. 1, no. 4, pages 48-53), this is essential if inheritance is to provide support for reusability in a practical industrial context. Garbage collection This item and the next violate Mr. Geary's request to limit the discussion to language features. I have included them anyhow because, even though they are environment rather than language features, they are made possible or next-to-impossible by the language design. To write serious object-oriented software, which at run time will inevitably generate many objects, some of which may become useless, one needs a good garbage collector. This is the case in Eiffel (which uses an incremental, parallel scheme so as not to impair performance). As far as I know, C++ systems do not support garbage collection, which would be extremely difficult if not impossible to implement because of the presence of C types and mechanisms. Automatic recompilation One of the most important practical aspects of Eiffel is the automatic compilation mechanism, based on automatic analysis of inter-class dependencies (multiple inheritance and client). This removes the need for make files and include files. Although I recall some seemingly interminable notes on the feasibility (or lack thereof) of a similar mechanism in comp.lang.c++, I don't know of any implemented mechanism for C++. Again, this seems due to the very design of the language; and again, the difference seems to result from irreconcilable views of what should be done by computers and what should be the province of humans. The Eiffel view is that error-prone and tedious management tasks should be handled by tools, and that programmers should concentrate on solving programming problems. Pointer arithmetic etc. One of my major objections to C++ stems from what that language has rather than what it has not. Because C++ retains almost total compatibility with C, it keeps all its low-level and dangerous features. The design of C dates back to the late sixties and is obsolete by modern software engineering standards. Compatibility with C means that in C++ you still have pointers, type casts, pointer arithmetic, function pointers, malloc, free, bizarre operator precedence (the famous asterisk/parenthesis bugs), weak type checking and so on. I strongly disagree with this approach if the goal is to obtain software quality. Take pointer arithmetic, for example. I would contend that you can have quality software, or you can have pointer arithmetic; but you cannot have both. In Eiffel, the choice has been made. None of these low-level features are present (as John Sarkela pointed out in a previous message); needless to say, they are not missed. Compatibility with C software C++ is obviously very compatible with C. But in Eiffel too you can easily communicate with C software; both call-in and call-out are provided. This makes it possible to reuse existing software easily. The need for such communication was not, however, deemed to be a good argument for impairing the consistency of the language itself. Simplicity and ease of learning Much of the plea for C++ is based on the observation that it provides an easy transition from C, which (for better or worse) is the language many programmers know nowadays. Using Dr. Brad Cox's expression (meant for Objective-C), this supports an ``evolutionary'' approach. I can certainly respect this view and its appeal to software managers in industry. But I believe that by considering it more closely one will find it short-sighted and ill-founded. Learning a new language such as Eiffel is nothing for a competent programmer. For Eiffel, which is small and simple, the learning process typically lasts a few days at most. Nobody has ever told us that Eiffel was difficult to learn. (If you read this, have tried to learn Eiffel, and found otherwise, please respond!) I believe that the process of going to Eiffel is in fact much smoother, as you don't have to use a confusing mix of old and new concepts. In a language that you master totally, you feel confident and you can concentrate on your job rather than on the language intricacies. Also, the brief initial shock produced by the realization that you cannot easily write your programs in a traditional way any more is, in the experience reported by Eiffel users, highly salutary. 3 - CONCEPTUAL DIFFERENCES -------------------------- The considerable differences listed above more than offset, in my mind, any similarity that may seem to exist between Eiffel and C++. Beyond these individual technical differences, the contrast between the two languages is deep and conceptual. Eiffel is a new language and environment designed with a precise charter (enabling the production of very high quality software by professional programmers). C++, as I see it, is an attempt at a more modern version of C. (The basic C++ reference quoted above, in its ``historical note'' on page 5, writes that ``the difference between C and C++ is primarily in the degree of emphasis on types and structures'') . There are undoubtedly arguments for both approaches. Needless to say, I find the arguments for the first to be stronger. -------------------- This is probably overkill already and I shall resist the temptation to go on. Have I at least succeeded in convincing Mr. Geary that the technical differences are deep ones? In all likelihood, this note, prompted by Mr. Geary's question, will eventually be rewritten as a short article, so that comments and criticism will be greatly appreciated. -- Bertrand Meyer bertrand@eiffel.com
bertrand@eiffel.UUCP (Bertrand Meyer) (06/05/89)
``Ia pamiatnik siebie vosdvig nierukotvornyi...''
Aleksandr Pushkin
``A la septieme fois, les murailles tomberent.''
Victor Hugo
``Eppur si muove.''
Galileo Galilei
``You can fool, etc.''
Abraham Lincoln
From message <2689@ssc-vax.UUCP> by dmg@ssc-vax.UUCP (David Geary):
> I would like to start a discussion of Eiffel vs. C++.
A previous note described my view of the differences between the
two languages. There is another side to the story, however.
Mr. Geary's message painfully reminded me that the kind of
comparative discussion he calls for
(a desire many other people undoubtedly share)
should normally have been held live next October in a public forum.
At the 1988 edition of OOPSLA (the ACM conference on
object-oriented programming), a well-known and respected
Professor from a university on the East Coast invited me
to participate in a panel at the next conference
(New Orleans, early October 1989). The idea for the panel was
to discuss the designs of major object-oriented languages, with
the Eiffel, Smalltalk, C++ and Objective-C viewpoints presented
respectively by myself, Dr. Adele Goldberg from ParcPlace, Dr. Bjarne
Stroustrup from AT&T and Dr. Brad Cox from Stepstone. This looked liked a
great idea and I agreed immediately.
Some time later I was told that I was out of the panel. The reason:
Dr. Stroustrup had declared that he would not participate if I did.
Perhaps even more stunning than Dr. Stroustrup's reaction was the panel
organizer's apparent inference that, if A refuses to be on a panel with B
(who himself welcomes the opportunity), then B should be excluded.
Then as now I did not understand why the inference is not that A must be
taken to his word.
I do not know the current status of the panel proposal and
have not been contacted again for that panel. A letter and an e-mail
message to the organizer remained unanswered. Clearly there will be
no opportunity for attendees of OOPSLA '89 to hear about
the comparative designs of Eiffel and C++.
In a way, this whole story confirms that we must be doing
something right. If the developer of C++, backed by the immense
resources of one of the largest and richest companies in the world,
by constant one-sided propaganda in the technical media, by a strong
position in the organization of OOPSLA, and by countless
other assets having to do with the sheer size and wealth of
the supporting organization, can find no better argument
to defend C++ than exclusion of any reference to Eiffel in public forums,
then he must be rather scared indeed.
There is no doubt that censorship of this nature will have damaging
immediate effects on the recognition of Eiffel's contribution to the
cause of software engineering. The history of such cases over the past
three years amply demonstrates this. But it is a folly to believe that
good ideas can be suppressed for very long. Many people,
some of whom were quoted at the beginning of this note,
have said it much better than I ever could.
Money, power and intimidation cannot buy everything. Once the lights
are out, the hype is gone, the pre-settled panels have been held and
the biased articles have been read, sooner or later people will go
home and start to work. Then they will judge on costs and benefits,
not promises and politics.
Among the readers of comp.lang.c++, there are two non-disjoint
groups whose reaction to the present situation is of particular interest.
One is AT&T's employees and particularly its researchers, whose contributions
to computing science have been so impressive over the past 30 years.
Blaming a large organization for the individual behavior of each of
its workers would be unfair and stupid. But when the misdirected
efforts of one or more employees of a multi-billion dollar company
leave the (right or wrong) impression that the company is trying
to crush a group of independent, free-spirited scientists, simply
because they have had another idea and work hard to push it -
I doubt their colleagues feel very proud.
The other group is C++ users and enthusiasts. Many of them undoubtedly
love C++ for highly respectable reasons and neither I nor anyone else
may ever be able to convince them that Eiffel is better for what they do.
Having everyone agree on any single topic, even if it is just the
programming language - what a horrible prospect! But regardless
of any difference in technical opinions, I would be surprised if
they did not keep open minds. Am I wrong in assuming that they, too,
want to base their decisions on rational arguments clearly expressed,
not on the autocratic suppression of alternative approaches?
-- Bertrand Meyer
bertrand@eiffel.combs@alice.UUCP (Bjarne Stroustrup) (06/06/89)
Bertrand Meyer, president of Interactive Software Engineering, the supplier of Eiffel, is correct on one point: I did refuse to appear on a panel with him. My reasons are personal. He has insulted my friends and colleagues in public; he has attacked me in public and in private; he has misrepresented and maligned my technical work; his company's advertising has quoted me out of context and without permission. Technical discussion requires more common courtesy and more detachment from commercial concerns. Meyer complains about censorship, money, power, and intimidation. There is no censorship and no conspiracy against him, his company, or his language; the very notion is ridiculous. In fact, it is evident that ISE's marketing budget for Eiffel vastly exceeds AT&T's minimal marketing budget for C++ (not a cent of which is spent attacking anyone). As to the merits of Eiffel, C++, or any other language, users will decide. Comp.lang is for programmers, not corporate paranoia.
lam@tridom.uucp (Larry Morris) (06/06/89)
In article <150@eiffel.UUCP>, bertrand@eiffel.UUCP (Bertrand Meyer) writes: > > Finally I do not think that in the long term Eiffel is really > ``competing'' with C++. They have almost nothing in common in their aim > and spirit, as explained in the final section of this message. > In my undoubtedly biased view, the real competitor to Eiffel is Ada. > (``Competitor'' for me is a positive word. When you acknowledge > a design as a competitor to yours, it implies respect.) > Ada, as already mentioned, is not truly object-oriented, but its official > charter (reliability, reusability, professional high-quality software > development etc.) is very similar, on paper at least, to that of Eiffel. > I find this view surprising, even though I'm willing to concede that Eiffel is radically different from C++, and more modern in its design. Ada, from what I've seen, is used more by mandate than choice [not that it's a particularly "bad" language, but I'd be willing to bet that nearly all new engineering users of Ada have a DoD standard on their desks]. Setting up Ada as the "competition" seems like a strawman to me. As for the "charter" of C++, was it intended for unreliable, one-time, amateur, poor-quality software development? I doubt that Stroustrup's intent was significantly different than yours. I see C++, Objective-C and Smalltalk as Eiffel's most obvious competitors for the engineering marketplace, as much for political as design considerations. Ada is likely to remain comfortably entrenched in its own well-protected market. > can talk about the very idea of reusable software components without > assertions... > maintained by the amplifier). Yet of widely available programming > languages, only Eiffel has these notions. Assertion checkers, of course, have been used for years as tools outside the scope of the language, as libraries, or extracted by tools from code comments. Placing assertions within classes as part of the language is, I must agree, a very powerful feature. But Eiffel's design philosophy calls on programmers to define their classes with assertions in addition to coding their implementation; something most programmers aren't used to doing and may view as an onerous task. Since assertion checking isn't any better than the assertions dreamed up by the programmer, I'm skeptical of using it to "replace" unit testing. > > Eiffel has exception handling. Its exception mechanism is original and > I believe it is one of our major contributions, based on the theory of > ``Programming by Contract''. As far as I know, there is > no exception mechanism in C++. I believe that one cannot write > serious software without having a way to recover cleanly from unexpected > cases. > I agree 100% with this, and I view it as the single biggest selling point of Eiffel over C++. > > In C++ as in Ada a routine may be declared as ``in-line'', meaning > that calls will be expanded in-line to gain performance. No such mechanism > is available in Eiffel.... > The optimizer will automatically > expand certain routines in-line based on systematic criteria beyond > programmer control... > I'm a bit skeptical about this approach. In data communications software (or other types of real-time software) it's frequently necessary to optimize certain methods heavily. I'd like some choice over this without having to resort to an assembly language or C call-out. How many times must I reference the method before your optimizer decides to inline it? How many lines may I add to the method before your approach changes? By adding a line, will I speed things up or slow them down? > > To write serious object-oriented software, which at run time will > inevitably generate many objects, some of which may become useless, > one needs a good garbage collector. This is the case in Eiffel > (which uses an incremental, parallel scheme so as not to impair performance). > As far as I know, C++ systems do not support garbage collection, > which would be extremely difficult if not impossible to implement > because of the presence of C types and mechanisms. Obviously, one does not need a good garbage collector if one cleans up after oneself. Having been burned before by garbage collection, I remain wary of claims of efficiency. With C++, I control allocation and deallocation of memory resources explicitly, so I know their performance impact. With Eiffel, do I just trust that you won't collect garbage at an inopportune time, like halfway through emitting a frame? > Compatibility with C means that in C++ you still have pointers, > type casts, pointer arithmetic, function pointers, malloc, free, bizarre > operator precedence (the famous asterisk/parenthesis bugs), > weak type checking and so on. > In Eiffel, the choice has been made. None of these low-level features > are present (as John Sarkela pointed out in a previous message); needless > to say, they are not missed. In analyzing incoming data frames, we freqently encounter the problem of extracting or adding variable-length headers, at various positions in a byte array. It's most convenient (and efficient) to be able to adjust a byte pointer, then reinterpret the pointer as a struct pointer. This may not be "textbook" programming style, but life isn't filled with textbook problems either. The pragmatism of C in these situations is one reason I prefer it to Pascal these days, and why I endure all of C's warts. Yes, I want many of the benefits of Eiffel...but when I need just to get the job done, will I be calling my old C routines because your choices didn't fit? > Learning a new language such as Eiffel is nothing for a > competent programmer. For Eiffel, which is small and simple, > the learning process typically lasts a few days at most. Natch! I learned C in a few days, few being a relative term. Becoming fully versed and competent took a "few" more, and I might still have a couple days to go. You're probably right about being easier to learn than C++, though, not having the forward interference from C to contend with. As someone involved in the selection of an OOP language, I have to say that the decision between C++ and Eiffel isn't a trivial one. Many of the factors are political, since C++ has a large and "grass-roots" support base, while Eiffel is relatively new to the scene, and more academic in its "feel." I think the decision will be influenced strongly by support tools, since successful OOP programming, IMHO, depends on making classes available to a team in an accessible and controllable manner. Eiffel has a solid, but largely proprietary, environment set; C++ seems bogged down in this area, but with many vendors interested. I hope both ISE and AT&T feel some healthy competition between their products, since this will encourage more tool development. These days a language can't be considered realistically outside of its tool environment; this goes double for an OOP language. Larry Morris, Tridom Corporation ...!emory!tridom!lam
rfg@pink.ACA.MCC.COM (Ron Guilmette) (06/06/89)
In article <149@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: >From article <6590138@hplsla.HP.COM> by jima@hplsla.HP.COM (Jim Adcock): >> >> I have heard rumers [sic] that there are a lot more problems in general with >> compilers for Eiffel than with compilers for C++. Perhaps someone can >> illuminate. First, make that "compiler" not "compilers". I believe that there is only one. That number is only two less than the number of C++ compilers, but it is worth noting if you are like a paranoid hardware manufacturer and you want to be assured of a second source. I had the opportunity to play with Eiffel for awhile once about two years ago. The compiler was just fine, even then. It is probably even better now. Nonetheless, I'm playing C++ these dayz and I'm glad. Even though the Eiffel compiler was fine, I didn't much like that language itself. Now I don't want to get into an argument with Bertrand or anybody else about it. It is just a matter of personal taste. "Each to his own" I say. Let every man choose his own tools For me, Eiffel was kind of like a chastity belt. It definitely keeps you "pure" but you will probably have less fun. :-) -- // Ron Guilmette - MCC - Experimental Systems Kit Project // 3500 West Balcones Center Drive, Austin, TX 78759 - (512)338-3740 // ARPA: rfg@mcc.com // UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg
aro@aber-cs.UUCP (Andrew Ormsby) (06/06/89)
In article <2689@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: > I've been programming in C for about 5 years, and >just recently started using C++. I would like to >start a discussion of Eiffel vs. C++. I understand >that both languages use C as a base language, and >that both implement OOP features, and it seems as >though the two have much more in common, aside from >syntactic differences, than they have differences. It is true that current implementations of Eiffel use C as a base language. With Eiffel, however, the use of C is really as a portable assembler that the Eiffel translator can compile into. This has presumably greatly reduced the development costs of the compiler for Interactive Software Engineering, Meyer's firm. There is the added advantage that it enables them to make use of the machine dependent optimisers that are usually part of the C compilation systems on various machines. However, I would contend that the fact that Eiffel uses C as a "base language" is only an implementation detail. C++ is very different. To quote Stroustrup in the introduction to the C++ book, "Except for minor details, C++ is a superset of the C programming language". C++, quite deliberately, therefore ends up looking very much like C. While most current C++ translators are implemented as preprocessors for C compilers, there are a growing number of true C++ compilers. My view is that C++ is what people should be using as an alternative for C in applications where C was really necessary; where there are programmers around who know how to use it properly. My worry is that C++'s additional complexity over and above C will make it even more likely that bad C++ programs are written. Eiffel may be more appropriate as a general purpose language; my personal opinion is that it looks likely to be less easily misused. However, C++ is widely available and cheap. Eiffel is less widely available and rather expensive. Its a shame. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >~ David Geary, Boeing Aerospace, Seattle ~ >~ "I wish I lived where it *only* rains 364 days a year" ~ >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Andy Ormsby, aro@cs.aber.ac.uk Department of Computer Science, aro%cs.aber.ac.uk@nsf-relay.ac.uk University College of Wales, aro%cs.aber.ac.uk@ukacrl.bitnet Aberystwyth, Dyfed, UK, SY23 3BZ.
mgardi@watdcsu.waterloo.edu (M.Gardi - ICR) (06/06/89)
I have heard that eiffel creates hideously large executables from very trivial programs. Does anyone have any information as to whether this is true or not?? I found that using advantage C++ also produced large executables...one of the reason why I am using Zortech C_++ currently. It does not seem to have this problem (executable size seems on average to be about 1/5 the size of advantage c++ code). We're talking 35K here for a hello world program in advantage...something that can't be tolerated on the PC. One source gave the comparable eiffel program a number even much higher. Peter DeVries Mutual Life of Canada (519) 888-2957 c/o mgardi@watdcsu
jwg1@bunny.gte.com (James W. Gish) (06/06/89)
In article <150@eiffel.UUCP> Bertrand Meyer writes: > C++ is obviously very compatible with C. But in Eiffel too you can >easily communicate with C software; both call-in and call-out are >provided. This makes it possible to reuse existing software easily. >The need for such communication was not, however, deemed to be a good >argument for impairing the consistency of the language itself. > I believe this should be qualified somewhat. You indeed can make calls to C routines from Eiffel and vice versa. But life is rarely that simple. You have to map Eiffel objects to C structures and vice versa. This is tedious but can be done in some/most(?) cases. One of the biggest problems that keeps calls from Eiffel to C non-trivial is the inability to use C include files within Eiffel for the definition of types on the Eiffel side. This is a serious obstacle to making use of much C code. A case in point is the use of X. (There are other problems here such as callbacks, but I don't want to go into that here). Much of the X stuff is defined in C header files. To make use of these header files within Eiffel requires either a manual or user-defined automatic translation mechanism. I don't expect miracles here and I don't expect ISE to come up with solutions to the problems generated by C language design sins or the poor coding practice of some C programmers, I just want to point out that the statement "...in Eiffel too you can easily communicate with C software; both call-in and call-out are provided" does not tell the whole story. Also, with respect to reusing existing software easily, it definitely is NOT easy to make use of existing X code, particulary existing widgets. We've made a serious attempt at it and can do it with some success, but it is not fun or easy. And please correct me if I'm wrong, but having the X-based graphics classes will not make it any easier to (re)use existing widget sets either. > >Simplicity and ease of learning > > Much of the plea for C++ is based on the observation that it provides >an easy transition from C, which (for better or worse) is the language >many programmers know nowadays. Using Dr. Brad Cox's expression (meant >for Objective-C), this supports an ``evolutionary'' approach. > > I can certainly respect this view and its appeal to software managers >in industry. But I believe that by considering it more closely one will >find it short-sighted and ill-founded. > > Learning a new language such as Eiffel is nothing for a >competent programmer. For Eiffel, which is small and simple, >the learning process typically lasts a few days at most. >Nobody has ever told us that Eiffel was difficult to learn. >(If you read this, have tried to learn Eiffel, >and found otherwise, please respond!) I believe that the process of >going to Eiffel is in fact much smoother, as you don't have to use >a confusing mix of old and new concepts. >In a language that you master totally, you feel >confident and you can concentrate on your job rather than on >the language intricacies. I agree that learning a new language is nothing for a competent programmer. However to learn to program effectively and efficiently in a new language takes much more than a few days, especially if one is switching paradigms. Learning to use the language fully and understand its subtleties is a long term affair. I have been using Eiffel for several months and still don't feel like an expert - nor did I expect that I would. One of the obstacles to learning is the lack of a comprehensive language reference manual. I was pleased to read that one is forthcoming. Another obstacle, which I believe another poster already stated, is the lack of thorough documentation for the library classes. At times, I have had to write test programs or actually look at the source code for the classes to figure out how to use them. A case in point is the class H_TABLE. I wanted to dump the non-null entries of a an H_TABLE that I created. I thought that I could loop through it using entry(i) with i going from 0 to nb_elements-1. Unfortunately, it wasn't that simple, since entry(i) doesn't return the non-null entries like I expected it would. Better documentation would have prevented me from making this mistake. Examples in the documentation could alleviate some of the confusion. > > Also, the brief initial shock produced by the realization that you >cannot easily write your programs in a traditional way any more is, >in the experience reported by Eiffel users, highly salutary. > But still requires a considerable realignment of ones neurons :-) -- Jim Gish GTE Laboratories, Inc., Waltham, MA CSNET: jgish@gte.com UUCP: ..!harvard!bunny!jwg1
sjs@spectral.ctt.bellcore.com (Stan Switzer) (06/06/89)
In article <77300027@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > If you are not a C shop, or if you are unhappy with C, then I would > recommend giving Eiffel a close look. By that I don't mean reading > the book. Instead, buy a copy of the compiler and use it. That is > the best way to learn about a language and to be certain of the > reliability and speed of an implemantation. If, on the other hand, you ARE a C shop and are happy with C, then I would recommend giving Eiffel a close look. By that I don't mean buying and using the compiler. Instead, buy a copy of the book and read it. It never hurts to take a look at other ideas. Although I find the syntax a bit tedious, Eiffel is an exceptionally well-thought-out language design. Stan Switzer sjs@ctt.bellcore.com "Plagiarism is the sincerest form of imitation."
johnson@p.cs.uiuc.edu (06/06/89)
> Written 6:48 pm Jun 4, 1989 by bertrand@eiffel.com Responses written by Ralph Johnson >2 - TECHNICAL DIFFERENCES >------------------------- > >Software structure > > Eiffel software is organized in autonomous software units >(classes), meant to be compiled separately. There is no main program. >This is what I believe should be the case in object-oriented >programming. In contrast, I understand that C++ still follows >the traditional C model. Quoting from Dr. Bjarne Stroustrup's ``The >C++ Programming Language'' (Addison-Wesley, 1986), which seems to be the >major reference on C++, page 22, lines 13-14: ``A C++ program typically >consists of many source files, each containing a sequence of declarations >of types, functions, variables, and constants''. This is very far from the >object-oriented model of software decomposition. Furthermore, reports from >actual users of C++ seem to indicate a heavy use of ``include files'', a >technique which I don't fully understand in the C++ context, and which >has no equivalent in Eiffel. In practice, C++ is not much different from Eiffel. Programmers spend most of their time writing classes. There are large libraries of class definitions, each of which is reused in several applications. It is true that there is a "main program" that creates the objects of the application program and starts the initial thread of control, but it is usually very small. Include files are used to let the implementation of one class know about the specification of another. Probably the programming environment carries out this function in Eiffel. Since C++ is an extension of C, programmers can continue to write C++ in the C style, and I am sure that many do. However, they are missing the point of reusable software and object-oriented programming. >Assertions I think that assertions are one of the most attractive things about Eiffel. I said this to a more theoretical member of my department, and he made a snide remark, after which he pointed out that there are many assertions one might want to make about programs that the Eiffel assertion language will not let you make. This is a bogus argument! Eiffel assertions are a first step to making the theory of software verification practical. There can be no doubt that they are much more powerful than any other assertion method in wide use that provides more than documentation. It seems obvious to me that they will help make software a lot more reliable. Having said that, I would like to argue with the claim that languages without assertions cannot support reuse. There are a lot of ways to learn how to reuse a class other than looking at the assertions associated with its functions. Natural language documentation can not only do the job as well, but can NEVER be replaced by assertions. Given the choice of assertions or good comments, I'll choose good comments. Of course, there is no reason not to have both. I think that we will see assertions become a formal part of more languages. It is interesting to note that our operating system written in C++ makes heavy use of assertions. A student implemented assertions using a macro package. It would be nice to have them be a part of the langauge, but they are valuable even with compiler support. >Exceptions The Eiffel exception handling scheme is very nice. >Global variables Although C++ supports C style global variables, there is no reason that you have to use them. In practice, global variables usually are constant objects, just as in Eiffel. >Genericity Another major advantage to Eiffel. However, C++ isn't as bad as you suggest. It is possible to use a macro processor to implement generic classes. This results in all the problems of macros, since type-checking errors appear in the substituted code, not in the original. The GNU C++ compiler has a set of tools that help make this process as painless as possible. It would be better if the language implemented it directly, of course. >Dynamic binding This is not that big a deal, either. Just declare every (or almost every) function to be virtual. Only optimize those parts of a program that are inner loops. I applaud the Eiffel approach of making the compiler responsible for finding the most efficient way to implement a program. One of the bad things that C++ has inherited from C is the assumption that optimizing compilers are too hard to build and low-level optimizations are the programmer's responsibility. This assumption was probably true 20 years ago, but it isn't true any more. A good example is having to declare which variables are stored in registers. Pointer arithmetic also falls in this category. >Consistency of the type system >Type checking > Because of the absence of genericity and the presence of the full C >type system with its casts and other unsafe mechanisms, C++ cannot be >reasonably be called a statically typed language. In contrast, Eiffel was >designed as fully typed. There is no doubt but that Eiffel's type system is better than that of C++. However, in my opinion, C++ is a statically typed language. It just is not type-safe. Static type checking just means that the compiler does the work, not the run-time system. >Deferred classes Any C++ class with virtual functions can be a deferred class. The linker (not the compiler) demands an implementation for each function, but it is easy to define a function that does nothing except print an error message. >Multiple inheritance Some of us, even outside AT&T, have had multiple inheritance available for a long time. In my opinion, multiple inheritance is grossly overrated. A good clean design usually eliminates the need for multiple inheritance. The main reason that multiple inheritance is needed is for type-checking. >Garbage collection This is both a major advantage and disadvantage. Would you advise us writing our operating system in Eiffel instead of C++? What impact does your garbage collector have on real-time software? For years I have told people that C is the world's best assembly language. Since the Eiffel compiler produces C, I guess you agree. However, most software should be written in a high-level language. C++ is better than C, so I suppose that it is now the world's best assembly language. There are plenty of cases, such as device drivers, that require assembly language, something whose performance can be absolutely predicted from the source code and that lets individual bits of I/O registers be manipulated. However, for most software, including compilers as well as application software, a high-level language is better. >Automatic recompilation Experienced Unix programmers can fake something similar with make. Eventually there will be C++ programming environments, such as Cynergy, that will do it correctly. One of the questions that many people have about Eiffel is its efficiency. I've made lots of loud remarks about how optimizing compilers can do a good enough job that there is no need to force the programmer to have to think about pointers and how a function call is implemented. However, is Eiffel an existence proof for my argument? Do you have any benchmarks comparing Eiffel and C++? Ralph Johnson >Bertrand Meyer
jima@hplsla.HP.COM (Jim Adcock) (06/07/89)
> > I have heard rumers [sic] that there are a lot more problems in general with > > compilers for Eiffel than with compilers for C++. Perhaps someone can > > illuminate. > > I'll be straightforward. We, the developers of Eiffel, are fed up > with ``rumers'' and slander. That the proponents of C++ are desperate > for technical arguments is understandable, but does not justify everything. Well, for what its worth, the "rumers" I was talking about can from people who are evaluating a wide variety of OOPLs -- not C++ "proponents" or vendors. People who consistently read this notes string know I am less than totally enamored of the quality of C++ compilers too. But, I am convinced that C++ compilers are now good enough to do serious commercial work. Since I was unable to verify these Eiffel problems myself [not having an Eiffel compiler], I labeled them "rumors." I don't know about "slander", but I do think Meyer could have presented a more honest portrayal of C++ than presented in his book. Still, I think he presents some interesting OOP points, if one is able to filter out all the dogma.
henry@utzoo.uucp (Henry Spencer) (06/07/89)
In article <233@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes: >For me, Eiffel was kind of like a chastity belt. It definitely keeps >you "pure" but you will probably have less fun. :-) It struck me, in fact, that a good many of Dr. Meyer's comparisons between C++ and Eiffel boiled down to "C++ lets the programmer foul things up in any way he pleases, while Eiffel insists on doing it right". This is, in fact, a long-standing philosophical difference between the C camp and the Pascal camp. C has always given you more than enough rope to hang yourself with, which means that writing clean, well-behaved programs in C requires competence, experience, and strict self-discipline... qualities that are all too rare in the real world. On the other hand, all that rope can be quite useful when the problem to be tamed is large and obstreperous. The Pascal side favors using the language to impose discipline, which makes it a LOT easier to get reliable, well-behaved programs but can make it harder to get the desired results with those programs. Which set of tradeoffs is better depends on the circumstances and the people. (Me? I find the Pascal theory very attractive but at the moment am fully in the C camp for pragmatic reasons. Combining the virtues of the two ought not to be impossible but seems to be difficult in practice. Perhaps a mixed approach is better than trying to pick one or the other.) -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jwg1@bunny.gte.com (James W. Gish) (06/07/89)
The following "Hello world" program generated an executable on a Sun3
of 147456 bytes:
class world
inherit
STD_FILES
feature
Create is
do
putstring( "Hello world." ); new_line;
end;
end
The .eiffel file used was:
------------ EIFFEL SYSTEM DESCRIPTION FILE -------------------
-- For simple uses, just replace ``root_class_name'' below
-- by the name of the root class of your system (lower case)
ROOT: world
SOURCE: /usr/proj126/Eiffel/library
EXTERNAL:
NO_ASSERTION_CHECK (N):
PRECONDITIONS (N):
ALL_ASSERTIONS (Y):
DEBUG (N):
TRACE (N):
OPTIMIZE (N):
GARBAGE_COLLECTION (N)
VIRTUAL_MEMORY (N)
C_PACKAGE (N):
C_EXTERNAL:
MAKE:
VISIBLE (N):
----------------------------------------------------------------
--
Jim Gish
GTE Laboratories, Inc., Waltham, MA
CSNET: jgish@gte.com UUCP: ..!harvard!bunny!jwg1schwartz@shire.cs.psu.edu (Scott Schwartz) (06/07/89)
In article <1989Jun6.171549.16028@utzoo.uucp>, henry@utzoo (Henry Spencer) writes: >(Me? I find the Pascal theory very attractive but at the moment am fully >in the C camp for pragmatic reasons. Combining the virtues of the two >ought not to be impossible but seems to be difficult in practice. Perhaps >a mixed approach is better than trying to pick one or the other.) Isn't this what Turing Plus tries to do? -- Scott Schwartz <schwartz@shire.cs.psu.edu>
bertrand@eiffel.UUCP (Bertrand Meyer) (06/07/89)
La calunnia: e` un venticello,
Un auretta assai gentile
che insensibile, sottile
incomincia, incomincia susurrar.
(The great Calumny aria from the Barber of Seville)
I have never had any personal business with Dr. Stroustrup.
Any personal hostility is his problem.
I let readers judge who is insulting whom. For my part,
I have no time to waste on his personal attacks, not a single one
of which is true.
In my previous message, I stated a fact: Eiffel has been
excluded from a projected OOPSLA panel on the design of object-oriented
languages. This is in the public record and now confirmed by
the party that caused the exclusion. Anyone can judge on the ethics
of the situation.
------------------------
Note: I am writing this just before leaving for a 3-week trip and I cannot
possibly answer the mail messages that I have received recently.
I will try to do so when I come back. I thank all the people who
wrote to me. A few of these messages disagreed on some points
of my technical note, although in my quick review I didn't find
anything that clearly invalidated something I wrote.
Several people mentioned that I should have included Turing among
the ``commonly available languages'' supporting assertions. I guess
I was not aware that Turing was so commonly available in
universities. In any case I am happy to correct the omission and
to admit that my Turing could benefit from some brushing up.
--
-- Bertrand Meyer
bertrand@eiffel.commbenveni@irisa.irisa.fr (benveniste marc,lsp) (06/07/89)
From article <77300027@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu: > > My favorite language is Smalltalk. I also do a lot of C++ programming. > I have never programmed in Eiffel, but I read the book. > > Eiffel is a much more elegant language than C++. C++ is more-or-less > upward compatible with C, which is both its greatest strength and its > greatest weakness. C programmers will find it easy to program in C++, > though they might take a while to learn how to use it to best advantage. > Since there are so many C programmers, this means that C++ has a tremendous > marketing advantage. ^^^^^^^^^ Although It may sound anachronistic and/or idealistic, I believe that programming languages should be chosen based on criteria such as security (in its wider sense), reliability, extensibility, readability etc. rather than by its marketing advantage or upwards compatibility with widespread traditions. We surely don't want to reinvent the wheel, but we can't let an inadequate component flaw a design just because everybody likes it and works with it; we would be trapped in a vicious circle. Disclaimer: No affiliation... except, perhaps, candidness.
henry@utzoo.uucp (Henry Spencer) (06/08/89)
In article <4684@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: >>(Me? I find the Pascal theory very attractive but at the moment am fully >>in the C camp for pragmatic reasons. Combining the virtues of the two >>ought not to be impossible but seems to be difficult in practice. Perhaps >>a mixed approach is better than trying to pick one or the other.) > >Isn't this what Turing Plus tries to do? There are several languages that try to provide a "safe" subset and a more powerful version that can be used only in "unsafe" modules. (It's been a long time since I read about Turing Plus, but that's my vague memory of it; certainly this is Modula 3's approach.) There are two problems with this. First, restrictions on how unsafe code can be used are common (e.g. one must call a function to get at it). Second, the unsafe language is seldom anywhere near as powerful as, say, C -- it's usually the safe language with a few minimal, grudgingly-provided extensions. Things like pointer arithmetic, for example, are seldom directly available. The usual result is that it's easier to just write the unsafe parts in C and call them. You're going to have the function-call overhead anyway. That is what I meant by a mixed approach (as opposed to a combination): admit that you want two different languages, not a Dr.Jekyll/Mr.Hyde combination, and concentrate on clean interfaces and fast interlanguage calls. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
donahn@gypsum.berkeley.edu (Don Ahn) (06/08/89)
In article <5975@watdcsu.waterloo.edu> mgardi@watdcsu.waterloo.edu (M.Gardi - ICR) writes: > >I have heard that eiffel creates hideously large executables from very >trivial programs. Does anyone have any information as to whether this is >true or not?? I found that using advantage C++ also produced large >executables...one of the reason why I am using Zortech C_++ currently. It does >not seem to have this problem (executable size seems on average to be about >1/5 the size of advantage c++ code). >We're talking 35K here for a hello world program in advantage...something >that can't be tolerated on the PC. One source gave the comparable eiffel >program a number even much higher. What I'd be more interested in here is the INCREMENTAL increase in executable size due to program lines/functionality. Given the fact that eiffel has more functionality in it's run-time environment (built in garbage collection etc..) it is understandable that for "trivial" programs code size will seem to be unexplainably huge. This is not to say that the code size for a "hello, world\n" program is not completely unimportant. A extremely large amount of code for a "trivial" program may indicate an inefficient linker. But it does not necessary mean that the compiler is a dog. A more meaningful comparison to me would be the executable size of two large "algorithmically equivalent" programs. Given the power that an OOPS gives you, re-useable and organized code, it may be possible to DECREASE your executable size over a non-OOPS language for large programs. Of course, a well implemented program in a lower-level language (C , assembler) will always be more efficient than an OOPS. The problem is, it gets exponentially harder to create a "well implemented" program as its size goes up in a low level language. As I see it, OOPS was created to help make LARGE programs maintainable. The merits of an OOPS should be measured in this realm.
jos@cs.vu.nl (Jos Warmer) (06/08/89)
In article <JWG1.89Jun6172452@bunny.gte.com> jwg1@bunny.gte.com (James W. Gish) writes: > >The following "Hello world" program generated an executable on a Sun3 >of 147456 bytes: [... removed ...] >The .eiffel file used was: > >ALL_ASSERTIONS (Y): >C_PACKAGE (N): The size of executables in Eiffel depends very much on the compile options. The smallest size will be reached when all assertions are turned off. And all optimizations like inline functions and others are only done when generating a C package. Using: ALL_ASSERTIONS(N): ALL C_PACKAGE (Y): C gives an executable of 73728 bytes. Using `strip world' gives 57344 bytes. (Eiffel Version 2.1b, SUN3.5) Besides, I do agree with Don Ahn: In article <25321@agate.BERKELEY.EDU> donahn@gypsum.berkeley.edu (Don Ahn) writes: > >What I'd be more interested in here is the INCREMENTAL increase in executable >size due to program lines/functionality. Given the fact that eiffel has more >functionality in it's run-time environment (built in garbage collection etc..) >it is understandable that for "trivial" programs code size will seem to be >unexplainably huge. ... Jos Warmer jos@cs.vu.nl ...uunet!mcvax!cs.vu.nl!jos -- Jos Warmer jos@cs.vu.nl ...uunet!mcvax!cs.vu.nl!jos
jans@tekgvs.LABS.TEK.COM (Jan Steinman) (06/09/89)
<mgardi@watdcsu.waterloo.edu (M.Gardi - ICR)> <A more meaningful comparison to me would be the executable size of two large "algorithmically equivalent" programs.> We have an application that is implemented in both Smalltalk and C++/Interviews/X11. When compiled with debugging on, the C++ version is much slower and nearly as large as the whole Smalltalk image, which contains much more functionality, and always has debugging available. This is not meant to start any kind of war, simply to point out than many comparisons of the sort compare apples with oranges. With debugging off, the C++ version is about 1/6 the size of the whole Smalltalk image, although graphics performance is still slower -- probably due to the many layers of software needed, while Smalltalk is able to BitBlt. :::::: Jan Steinman - N7JDB Electronic Systems Laboratory :::::: :::::: jans@tekgvs.LABS.TEK.COM Box 500, MS 50-370 (w)503/627-5881 :::::: :::::: jsteinma@caip.RUTGERS.EDU Beaverton, OR 97077 (h)503/657-7703 ::::::
plogan@mntgfx.mentor.com (Patrick Logan) (06/09/89)
In article <1989Jun6.171549.16028@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: :) In article <233@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette) writes: :) >For me, Eiffel was kind of like a chastity belt. It definitely keeps :) >you "pure" but you will probably have less fun. :-) :) :) It struck me, in fact, that a good many of Dr. Meyer's comparisons between :) C++ and Eiffel boiled down to "C++ lets the programmer foul things up in :) any way he pleases, while Eiffel insists on doing it right". This is, in :) fact, a long-standing philosophical difference between the C camp and the :) Pascal camp. Instead of the phrase "doing it right" I think it would be more fair to paraphrase with "doing it according to some principles of sound software construction." As I read it, the phrase "doing it right" carries more self-righteousness than I felt existed in the original article. The article mentioned or referred to the guiding principles. :) The Pascal side favors using the language to impose discipline, which makes it :) a LOT easier to get reliable, well-behaved programs but can make it harder :) to get the desired results with those programs. Which set of tradeoffs is :) better depends on the circumstances and the people. :) :) (Me? I find the Pascal theory very attractive but at the moment am fully :) in the C camp for pragmatic reasons. Combining the virtues of the two :) ought not to be impossible but seems to be difficult in practice. Perhaps :) a mixed approach is better than trying to pick one or the other.) :) -- :) You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology :) but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu The logic here seems to be the following: The argument of C++ vs. Eiffel is similar to the typical C vs. Pascal argument. Therefore Eiffel is in the Pascal "camp". Therefore Eiffel will have the same problems as Pascal. I wouldn't consider this sound logic. Its application could lead someone away from even attempting to evaluate Eiffel. -- Patrick Logan | ...!{decwrl,sequent,tessi}!mntgfx!plogan Mentor Graphics Corporation | plogan@pdx.MENTOR.COM Beaverton, Oregon | "My other computer is a Lisp machine."
snorri@rhi.hi.is (Snorri Agnarsson) (06/09/89)
From article <77300029@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu: > >> Written 6:48 pm Jun 4, 1989 by bertrand@eiffel.com > Responses written by Ralph Johnson > >>Assertions > I think that assertions are one of the most attractive things about > Eiffel. I said this to a more theoretical member of my department, > and he made a snide remark, after which he pointed out that there are > many assertions one might want to make about programs that the Eiffel > assertion language will not let you make. This is a bogus argument! Well -- I agree with that argument. However I agree with you that assertions are good (at least they are better than nothing), but I think well formulated preconditions and postconditions, written as documentation, are necessary and sufficient. Assertions can serve as scaffolding for testing. >>Garbage collection > > This is both a major advantage and disadvantage. Would you advise > us writing our operating system in Eiffel instead of C++? What > impact does your garbage collector have on real-time software? In my opinion garbage collection is the single most useful feature of a programming language. Without garbage collection polymorphism is severely handicapped and programmers tend to shy away from clean designs because of the restrictions imposed by the lack of garbage collection. Consider the following C function: Usage: x:=plus(y,z); Precondition: y and z contain integers represented as zero terminated character strings of digits. Postcondition: x contains the sum of y and z, as a zero terminated character string of digits. If C had garbage collection we could write code such as: x=plus(x,plus(y,z)); ... y=x; Instead we have to write as follows: t1=plus(y,z); t2=x; x=plus(x,t1); free(t1); free(t2); /* assuming that the string pointed to by t2 is not pointed to by any other variable */ ... y=strcpy(x); /* unless you want to risk multiple pointers to the same string, in which case you would need to be VERY CAREFUL when freeing that string */ It is often said that garbage collection is too costly, but I suggest that in the above example the solution with garbage collection is probably more efficient, both in programmer effort AND in the speed of the resulting program. By the way, if garbage collection is too expensive, how about 'malloc' and 'free'? Do you think those routines are less expensive? Why do you think so? We should also consider the effort needed to document memory management issues for our (reusable) modules. If garbage collection is not available we get two bad effects: 1) The effort of designing a module for a given problem, PLUS the effort of documenting all the memory management issues needed to use the module is too great. Therefore you do not design or use modules. Or perhaps you use them without adequate documentation, leaving a can of worms for future maintainers. 2) You put a lot of effort into designing, coding and documenting modules, including all the memory management issues the user needs to know about to use the modules, so as not to get memory leaks or heap smashes. The design document for the modules become so huge and complicated that nobody uses the modules (or, perhaps, the modules are used, but incorrectly). In my opinion garbage collection is the single most useful feature of Prolog, LISP, SmallTalk, Eiffel, CLU, etc., etc. How many would use the above languages if they did not have garbage collection? In my opinion, very few. > Ralph Johnson >>Bertrand Meyer -- Snorri Agnarsson | Internet: snorri@rhi.hi.is Taeknigardur, Dunhaga 5 | UUCP: ..!mcvax!hafro!rhi!snorri IS-107 Reykjavik, ICELAND
bs@alice.UUCP (Bjarne Stroustrup) (06/10/89)
I stated in an earlier message that I was unwilling to share a stage with Bertrand Meyer because of his grossly impolite and insulting behavior toward me, my friends, and professional colleagues. He replied that my claims are groundless. Clearly we cannot both be telling the truth. Many people who attended ECOOP'87, and some who attended OOPSLA '88, are in a position to know for themselves which of us is lying. Others can read this whole distasteful series of exchanges starting with Bertrand Meyer's original posting and make a guess. Bertrand Meyer's company's use of AT&T's name and quotes from my copyrighted works in its advertising (without permission, of course) is also available for all to see. The present exchange is in itself a good example of why I prefer to have as little as possible to do with Bertrand Meyer. He has too often failed to attain the minimal standards of common courtesy and detachment from commercial concerns necessary for a technical exchange. For example, `part two' of his technical comparison of C++ and Eiffel contained a litany of unfounded accusations using extreemely loaded vocabulary: `censorship, money, power, intimidation, hype, one-sided propaganda, scared indeed, suppressed, pre-settled panels, biased articles, trying to crush.' - Bjarne Stroustrup PS By replying to his postings I did enter into a public discussion with Bertrand Meyer. That was probably a mistake, but I considered it a very real danger that unanswered accusations could become accepted `fact.'
jima@hplsla.HP.COM (Jim Adcock) (06/10/89)
> We have an application that is implemented in both Smalltalk and > C++/Interviews/X11. When compiled with debugging on, the C++ version is much > slower and nearly as large as the whole Smalltalk image, which contains much > more functionality, and always has debugging available. Interesting. How did you make a Smalltalk version of X11?
johnson@p.cs.uiuc.edu (06/10/89)
Snorri Agnarsoon (snorri@rhi.hi.is) made some comments about my comments about assertions. Though he may not realize it, we agree. Then, in response to my comment on garbage collection, he says >In my opinion garbage collection is the single most useful feature >of a programming language. Without garbage collection polymorphism >is severely handicapped and programmers tend to shy away from clean >designs because of the restrictions imposed by the lack of garbage >collection. I am a Smalltalk and a C++ programmer. Smalltalk is a lot more fun to use, and I can build systems much faster with it. Garbage collection is a major reason, though probably >In my opinion garbage collection is the single most useful feature >of Prolog, LISP, SmallTalk, Eiffel, CLU, etc., etc. is an overstatement. However, my remark was specifically directed to real-time programming. Garbage collection does not get along very well with real-time programming. The Smalltalk garbage collectors are pretty good, usually only taking a fraction of a second to collect garbage. However, if this happened in a middle of an interrupt then even 1/4 a second is too long. I want every language I use to handle memory allocation and deallocation automatically. C++ constructors and destructors are nice, but are still too much work, and the examples that Snorri gave show that sometimes they are not sufficient. However, designing a language so that it provides complete memory management and still permits real-time control is an unsolved problem, as far as I know. True incremental garbage collection either requires special processor design or is very inefficient, and the real-time programming people don't like inefficiency, either. Thus, there are still very important application areas (and real-time programming is growing in importance) for which garbage collection is inappropriate. Many people do not know that it is possible to use a garbage collector in C++ or C. Hans Boehm has such a collector, which he developed for Russel. I just saw an announcement of a Modula-3 implementation, and they are using it, so it is pretty general purpose. This garbage collector is not fast, because it can make almost no assumptions about the layout of objects and so must be conservative. However, the main reason for a garbage collector in C++ would be to catch "space leaks", so it would not have to be called very often. Ralph Johnson
bigm@batserver.cs.uq.oz (Michael Pilling [Real people drink purple milk]) (06/11/89)
Larry Morris in a recent article writes > > can talk about the very idea of reusable software components without > > assertions... > > maintained by the amplifier). Yet of widely available programming > > languages, only Eiffel has these notions. > Assertion checkers, of course, have been used for years as tools outside > the scope of the language, as libraries, or extracted by tools from > code comments. Placing assertions within classes as part of the language > is, I must agree, a very powerful feature. But Eiffel's design philosophy > calls on programmers to define their classes with assertions in addition > to coding their implementation; something most programmers aren't used to > doing and may view as an onerous task. Since assertion checking isn't any > better than the assertions dreamed up by the programmer, I'm skeptical of > using it to "replace" unit testing. I have been encouraging my group software project students to use assertions, and have found that they take some time to get into the swing of writing effective and prudent assertions. This feeling is based on their reactions, I have yet to mark their code (uggggh). Like anything there is a learning curve and a few people will never really get the hang of it. This is not to say assertions are a bad feature, it mearly reveals those who should should be programming and those whose talents lie in other areas. (Perhaps they could help me with my spelling :-) ) I have been using assertions for 3 years and felt obliged to point out that they are not intended to "replace" unit testing but to simplify and augment it. I have found assertions to have the following benifits in whatever language you choose to implement them. 1. Carefully chosen assertions clarify your understanding of the code you are writing or reading and force you to reason about what you are really doing and it's consequences. I have found this to be the most important benifit. It allows you to produce clearer, simpler and more efficient CORRECT code. 2. Error detection is increased. You can't fix them if you don't find them. In a large library module, certain code may never be executed until it fails. This may be 2 or 5 years down the track. Or the error may not manifest 99% of the time because one errornous result in a record/structure is only occasionally accessed. Assertions add another layer of testing - those of self consistency and plausability e.g.s While traversing a doubly linked list you can assert that the current link points back to where you came from. A positive square root should be smaller than the input and when squared should give the input. 3. Errors are detected close to their occurence in space and time. Symptoms of the error may be much further away when the real causes have been obscured. This makes fixing the bug easier because you don't have to waste so much time looking for it. e.g. Space - Assertions fail in your binary search routine - jumping to the bottom half of the array actually gave you a smaller key!! Conclusion: The caller lied when they claimed the array was sorted. Saved from wasting time trying to debug the correct binary search routine. Time - Stange errors are occurring in your program. You suspect the memory arena's been trashed but have no idea who did it and when. Assertions can often detect the culprit soon after they commit the crime. 4. When you think you've fixed the bug the saftey net is still there to tell you you were wrong. In libraries this to can be useful to detect bugs in infrequently used code rather than letting them slip through unnoticed. 5. They can make programs more robust and protect data by stopping their progress in emergancy situations. Real Life example: Data General AOS/VS operating system utility "Exec" hung itself after uttering: Internal inconsistancy error - negative time encountered. In reality, one of the sysops had corrected the time of day because it was fast. Exec caught itself completing a task before it started and thought the clock hardware had failed. It correctly aborted system processing rather than risk damaging timestamps used for backups and other data consistancy functions. 6. You can avoid buggarising your code with error handlers. Why should you attempt to clean up other peoples mistakes. Your code is simpler and more likely to be correct. eg When I did the group software project I was the only one to use assertions. During intergration, people would run to me saying YOUR module had ANOTHER assertion failure. More often than not, I had the pleasure of replying "Oh, that means your not sorting that array you passed me like you were supposed to." I have personally found the use of assertions to save me 80% of my previous debugging time and effort. They allow you to tackle problems that would be almost insumountable otherwise, particularly when useing malloc & free. Like any good investment they pay many returns over a long period. Assertions should be included in the language (definition and compiler proper) so you can turn them off (at your own risk). Preprocessed assertions often produce much more code per assertion and can not check that your assertions do not have side effects. (Side effects prevent you from turning them off because you program behaves differently.) Michael Pilling, Computer Science Department, University of Queensland, St Lucia, 4067 Australia.
mark@drd.UUCP (Mark Lawrence) (06/12/89)
} From message <2689@ssc-vax.UUCP> by dmg@ssc-vax.UUCP (David Geary): } } > I would like to start a discussion of Eiffel vs. C++. And then bertrand@eiffel.UUCP (Bertrand Meyer) wrote: [...AmongOtherThings...] } Money, power and intimidation cannot buy everything. Once the lights } are out, the hype is gone, the pre-settled panels have been held and } the biased articles have been read, sooner or later people will go } home and start to work. Then they will judge on costs and benefits, } not promises and politics. I remember going to the vendors exhibit during the '87 Summer Usenix in Phoesnix (the occasion of the infamous Jobs line: "X is braindamaged and will fail...". hah.). I recall sitting down with Mr. Meyer at the time for a walkthrough of Eiffel (Cepage?) and trying to understand just what it _was_. I was impressed at the time with the possibilities of the environment (and still am, based on all that I've heard about it). But I'll never give it (nor Objective C) serious consideration for use in my company. For me, it boils down to the same reasons why I refuse to buy a Gould machine running MPX, a DEC machine running VMS or a DG machine running AOS. It's the same reason why I think it unreasonable to develop the UI portions of our applications in native SunViews. It's the same reason why I think it unwise to commit to a database interface that has no SQL capability. I want a choice. I am extremely uncomfortable with the prospect of a vendor who has me locked into their proprietary product telling me what is and isn't important in terms of bug fixes and new product features -- I'd like to be able to make that choice in a free market. Quite simply, Objective C and Eiffel don't give me that choice and C++ does. The former may be more elegant in design and execution and have some arguably better features and capabilities, but I'll only seriously consider the latter, warts (from its procedural heritage) and all. I suppose that if I could reshape the world to my own liking, I would choose software tools, implementation languages and pieces of systems on technical merit alone. But the world isn't like that and so I don't. What's more, it has nothing to do (from my perspective) with the power, money and what-have-you behind "The Telephone Company" (anybody for "The President's Analyst"?). Such inuendo seems to me to be a bit far-fetched.
boehm@flora.rice.edu (Hans Boehm) (06/12/89)
In article <77300030@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes: > ... Garbage collection does not get along >very well with real-time programming. The Smalltalk garbage >collectors are pretty good, usually only taking a fraction of a >second to collect garbage. However, if this happened in a middle >of an interrupt then even 1/4 a second is too long. > >... However, designing a language so that it >provides complete memory management and still permits real-time control >is an unsolved problem, as far as I know. True incremental garbage >collection either requires special processor design or is very inefficient, >and the real-time programming people don't like inefficiency, either. >Thus, there are still very important application areas (and real-time >programming is growing in importance) for which garbage collection is >inappropriate. Though I agree entirely with the content of Ralph's message, I am afraid that parts of it are likely to be misinterpreted. I know of no way to guarantee 1 millisecond response in the presence of a garbage collector running on a standard processor. However, there are a number of garbage collection schemes that use conventional paging hardware to provide somewhat larger granularity incremental behavior (cf., Appel, Ellis, and Li, ``Real-time Concurrent Collection on Stock Hardware'', SIGPLAN '88 Proceedings). My impression is that if you can afford to run in a virtual memory environment, you can afford an efficient garbage collector. If you can't afford virtual memory, you can't afford the collector without special hardware or noticable extra overhead. >Many people do not know that it is possible to use a garbage collector >in C++ or C. Hans Boehm has such a collector, which he developed for >Russel. I just saw an announcement of a Modula-3 implementation, and >they are using it, so it is pretty general purpose. This garbage collector >is not fast, because it can make almost no assumptions about the layout of >objects and so must be conservative. However, the main reason for a garbage >collector in C++ would be to catch "space leaks", so it would not have to >be called very often. > >Ralph Johnson Our garbage collector is slower than a good copying collector. But, as has been pointed out before, garbage collector performance tends to be judged by tougher standards than malloc/free performance. Garbage collectors are frequently used in environments where 1 allocation per 100 instructions is considered normal. Some standard malloc/free implementations are completely unusable under such conditions. We have sometimes seen performance improvements in going from the vendor supplied malloc/free implementation to our allocator with full garbage collection. The current collector is not incremental in any sense, so bursty response is a bit of a problem. But it is important to keep perspective on this as well. Very long garbage collection times usually arise only in systems that keep the editor/compiler/programming environment entirely in one address space, or for really large applications. Garbage collection times for a half full 1 Meg heap on a MIPS M/120 are on the order of 1/4 sec. Hans-J. Boehm
dan@oresoft.uu.net (Daniel Elbaum) (06/13/89)
Gee, this discussion reminds me--C is really a much better
programming language than Pascal. You all agree, don't you?
--
The workaday world must remain transparent to those who maintain it if
they are to find inspired within them a vision of the history they create.
({uunet,tektronix,reed,sun!nosun,osu-cis,psu-cs}!oresoft!(dan)@oresoft.uu.net)db@lfcs.ed.ac.uk (Dave Berry) (06/13/89)
In article <150@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: > C++ has a notion of friend function which, as I understand it, makes >it possible to define routines outside of the object-oriented framework. >There is nothing equivalent in Eiffel. This facility is not missed. In C++ a class A may define other classes to be its friends; these classes can access all attributes and members of A. From the book (OOSC), Eiffel does seem to have an equivalent, namely the facility where members may be exported to certain named classes only. Both mechanisms allow A to control access to part of itself. The Eiffel mechanism gives finer control. I don't know if this finer control will matter in practice. Friend functions in C++ are similar, but allow the integration of object oriented software with non-OO software, in keeping with the rest of the language. >Compatibility with C means that in C++ you still have pointers, type casts, >pointer arithmetic, function pointers, malloc, free. I strongly disagree >with this approach if the goal is to obtain software quality. In Eiffel, >the choice has been made. None of these low-level features are present; >needless to say, they are not missed. Except by all the people asking for them on USENET ( semi :-) ). I would say that languages don't encourage software quality if they require the use of low-level features unnecessarily. C & C++ undoubtably do so, although C++ will improve when type parameterisation and multiple inheritance are available. This doesn't mean that such features should not be provided. Sometimes some people need low-level control. What is important is that they should be able to hide their use of such features from the rest of the program. I find it odd that Meyer considers function pointers "low-level". There was some discussion of function parameters in Eiffel a couple of months ago, and they seemed to offer neater solutions (IMAO) to some problems than the alternative techniques. Treating functions as first order objects (or "nearly firat order" objects) is usually considered high level. Dave Berry, Laboratory for Foundations db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk of Computer Science, Edinburgh Uni. <Atlantic Ocean>!mcvax!ukc!lfcs!db Britain without the Queen is like a democracy without a monarch.
simpson@poseidon.uucp (Scott Simpson) (06/13/89)
In article <151@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: = At the 1988 edition of OOPSLA (the ACM conference on =object-oriented programming), a well-known and respected =Professor from a university on the East Coast invited me =to participate in a panel at the next conference =(New Orleans, early October 1989). The idea for the panel was =to discuss the designs of major object-oriented languages, with =the Eiffel, Smalltalk, C++ and Objective-C viewpoints presented =respectively by myself, Dr. Adele Goldberg from ParcPlace, Dr. Bjarne =Stroustrup from AT&T and Dr. Brad Cox from Stepstone. This looked liked a =great idea and I agreed immediately. = = Some time later I was told that I was out of the panel. The reason: =Dr. Stroustrup had declared that he would not participate if I did. =Perhaps even more stunning than Dr. Stroustrup's reaction was the panel =organizer's apparent inference that, if A refuses to be on a panel with B =(who himself welcomes the opportunity), then B should be excluded. =Then as now I did not understand why the inference is not that A must be =taken to his word. In article <9438@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: =Bertrand Meyer, president of Interactive Software Engineering, the =supplier of Eiffel, is correct on one point: I did refuse to appear on =a panel with him. My reasons are personal. He has insulted my friends This is censorship and this sucks. I would have kicked you off the panel. Am I the only one who finds this behavior reprehensible? The panel chair who withdrew his offer to Dr. Meyer gets an F for bad judgement too. Scott Simpson TRW Space and Defense Sector oberon!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)
newsuser@LTH.Se (LTH network news server) (06/13/89)
I do not like the current ``discussion'' between Bertrand Meyer and Bjarne Stroustrup. I think it was wrong to start it, and I think it is inappropriate for this news group. In particular, I think other people should refrain from commenting as no unbiased account for the actual circumstances is available. It is my hope that Bertrand Meyer and Bjarne Stroustrup will be able to bury the axe sometime in the future, so that they can benefit from each other's contributions to programming language design. So will the rest of us. Dag Bruck -- Department of Automatic Control Internet: dag@control.lth.se Lund Institute of Technology P. O. Box 118 Phone: +46 46-108779 S-221 00 Lund, SWEDEN Fax: +46 46-138118
bs@alice.UUCP (Bjarne Stroustrup) (06/13/89)
I hear that some people have gotten the impression that the proposed language designers' panel Bertrand Meyer was referring to was actually going to take place at OOPSLA'89 (with C++ represented and Eiffel not). This is not the case. As far as I know, the panel wasn't even proposed to OOPSLA. I have heard absolutely nothing about that panel since last October when I declined to be on it. I am not involved in the OOPSLA'89 planning process.
awd@dbase.UUCP (Alastair Dallas) (06/14/89)
In article <1267@irisa.UUCP>, mbenveni@irisa.irisa.fr (benveniste marc,lsp) writes: > From article <77300027@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu: > > > > Since there are so many C programmers, this means that C++ has a tremendous > > marketing advantage. > ^^^^^^^^^ > > Although It may sound anachronistic and/or idealistic, I believe that > programming languages should be chosen based on criteria such as security > (in its wider sense), reliability, extensibility, readability etc. rather > than by its marketing advantage or upwards compatibility with widespread > traditions. Yes, it does sound idealistic. Some will make the language choice without considering what everyone else is doing, but most will not. Speaking from my experience with the dBASE language throughout the '80s, the ability to ask questions, buy books, attend seminars, etc. when you are using a language definitely factors in. It's not working out exactly the way I thought it would after reading Ted Nelson or Alvin Toffler... Sure, the number of choices is greater, we have narrowcasting replacing broadcasting, but people of similar needs and interests still clump together. If you have three all-ballet channels on cable tv and you're a ballet nut, you're going to coordinate which one you watch with other ballet nuts so you can talk about it the next day. But I digress (massively)... Good luck to Eiffel, to Pal (the programming language inside Paradox), to Fred (the programming language inside Framework). This is a regenerative process; they each may be successful one day. Today, if I had to bet the mortgage money, I'd go with the numbers and bet on C++. /alastair/ Disclaimer: These are my opinions. Ashton-Tate doesn't speak for me, and I return the favor.
geof@nswitgould.OZ (Geoffrey Jones) (06/14/89)
In article <11991@nswitgould.OZ>, I wrote: > As a small issue in C++'s favour, each C++ class > can contain a destructor routine which is executed whenever an object > of that class is destroyed, which will be whenever the object goes out > of scope (e.g., at program termination) or whenever it is actively > deallocated from the dynamic memory pool. No such operation exists in > Eiffel. This makes certain types of programming awkward in the latter. Oh dear, searching through my comp.lang.eiffel archive I grepped on "destructor" and found to my surprise that Jos Warmer (jos@cs.vu.nl) had already raised this point in article <2152@vlot.cs.vu.nl>. I'll include a little of it here because the article has probably expired from most sites by now and many comp.lang.c++ people following this discussion won't have read it before: > Some problems with garbage collection: > > 1. In the library class FILE one can create a FILE object, open it and use it. > If the FILE object is not referenced anymore, the memory used by it > will be reclaimed by the garbage collector. > However, each file that is opened should be closed before the FILE object > is destroyed. > > This can not be forced by the FILE class, but it is left to the client. > It should be much safer if the FILE class could ensure that each file > is closed before the object pointing to it is destroyed. > [ ... much more removed ... ] > > A possible solution: > > In C++ so-called destructors can be defined. A destructor is a routine > that is called on an object when the object is being freed. > A destructor contains code that performs some cleanup before the object > is destroyed. > > These destructors can be used to solve the problems described above. > I cannot find a way to solve these problems in eiffel. Should such > a feature be added eiffel, or are there other solutions. In article <129@eiffel.UUCP> Bertrand Meyer (bertrand@eiffel.UUCP) follows up to provide a (patch) solution: > In version 2.2 the library class MEMORY will include an argumentless > procedure called dispose, to be invoked by the garbage collector (if > active) when an object is freed. The original version of this class > has an empty body and hence does nothing. Any class can inherit > from MEMORY and redefine this procedure to do something, for instance > close a file as in Mr. Warmer's example. > > Two caveats: > > - The exact details are still subject to change. > > - The next version (Eiffel 3, end of 1989) will support the > possibility of treating all objects as persistent (the set of all > objects of an Eiffel session becoming a database). In this context > the problem addressed by Mr. Warmer becomes part of a larger > requirement (describing what should be done to any object when > the session terminates, or when it is stored to a file by an automatic > mechanism). This means that the 2.2 solution may be overridden at that > time by a more general scheme. The version 2.2 solution is indeed a step in the right direction but I don't see that it should be the final answer. An "obvious" solution might be to imbue Eiffel's `Forget' with an enlarged semantics, thus moving the solution under the auspices of the language definition and away from all the ad hoccery involving strange class inheritences. I would propose that programmers could define their own `Forget' routines analogously to programmer-defined `Create's. Thus the responsibility to call server class terminating routines (e.g., `close' in class FILE) would be removed from the server's clients (as Dr Meyer's v2.2 solution seems to allow), as well as from the vagaries of the garbage collector which may or may not be active depending on all sorts of contingencies not the least of which is whether the GC was enabled at compile-time(!). I believe it would be proper if each class instance had its programmer-defined Forget routine called whenever that instance went out of scope of all other system objects, i.e., if a successful garbage sweep of the object could be made or whenever the program was terminating. Naturally these are only tentative thoughts which should be weighed in the light of added language complexity and so forth. However the problem of proper object termination is a real one that must be addressed in the not-too-distant future if Eiffel is to become a suitable platform for many types of computing tasks. Geof. ---------------------------------------------------------------------------- Geoffrey Jones ACSnet: geof@nswitgould.oz.AU Dept. of Computer Science ARPA: geof%nswitgould.oz.AU@uunet.UU.NET U. of Technology, Sydney UUCP: ...!munnari!nswitgould.oz.AU!geof P.O. Box 123, Or try: munnari!nswitgould.oz.AU!geof@uunet.UU.NET Broadway, 2007 AUSTRALIA Phone: (02) 218 9505 ----------------------------------------------------------------------------
awd@dbase.UUCP (Alastair Dallas) (06/15/89)
In article <1989Jun13.084057.2032@LTH.Se>, newsuser@LTH.Se (LTH network news server) writes: > > I do not like the current ``discussion'' between Bertrand Meyer and > Bjarne Stroustrup. I think it was wrong to start it, and I think... > > Dag Bruck I disagree. Yes, no one else on the net has anything but opinion to add to the discussion and the debate is more personal than factual. By some limited definition, the thread does not belong here because it is not suitable for a textbook. But why should we choose to define usenet that way? Primarily, because the channels would otherwise be clogged by unimportant chatter. I say we must encourage important people to use this network, even for less than important things--and I'm not convinced that this debate is unimportant. _Any_ discussion between Bjarne Stroustrup and Betrand Meyer, no matter how trivial, is interesting to me. If Wirth and Ritchie started calling each other names, I'd tune it to that, too. Further, isn't the process by which a new language achieves acceptance fascinating? You rarely meet technical people who say they enjoy either sales or politics, and yet those two activities have a huge influence on science and engineering. What if we had a record of the things that Edison, Westinghouse and Tesla said to each other? Are arguments only important in historical hindsight? /alastair/ Disclaimer: These are my opinions. Ashton-Tate doesn't speak for me, and I return the favor.
mjl@cs.rit.edu (06/15/89)
In article <9456@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: >Bertrand Meyer's company's use of >AT&T's name and quotes from my copyrighted works in its advertising >(without permission, of course) is also available for all to see. I don't want to get bogged down in the name calling and other vituperative rantings and ravings that have been going on in these newsgroups, but this sentence intimates that ISE and Dr. Meyer have done something improper with Dr. Stroustrup's work and AT&T's name. I assume Dr. Stroustrup refers to ads such as the one in the July 1988 issue of IEEE Software (inside the front cover). If so, then two points must be made: 1. Three of the four quotes refer to an article by Dr. Stroustrup in IEEE Software, and, as a member of the editorial board, I know that the copyright belongs to the IEEE (this is standard policy). 2. All of the quotes are short, and properly cited in the ad. As such, they are covered by the fair use doctrine, and ISE has done nothing improper in using them. I'll leave it to others to determine whether or not the quotations were used out of context. 3. The only reference to AT&T is in a footnote attached to a table comparing C++ to Eiffel, and simply is used to document the version of the C++ compiler used in the comparisons. Rather than slandering AT&T, this provides a service to readers of the ad. In short, there seems to be little basis for this particular complaint. Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {rutgers,cornell}!rochester!ritcv!mjl CSNET: mjl%rit@relay.cs.net INTERNET: mjl@cs.rit.edu
johnson@p.cs.uiuc.edu (06/15/89)
One of the original papers on the Xerox Cedar environment talked about the importance of garbage collection for long-lived programs. They claimed that it was virtually impossible to write a large program that allocated memory dynamically and NEVER lost a byte. Perhaps they just didn't try hard enough. Anyway, they found that many programs would run for a few months and then run out of memory. These programs would go for days at a time without losing memory, then the part of the program that contained the space leak would finally get exercized and memory usage would jump up. Eventually, the program would use up memory. I don't have much experience with programs like this, but I found their arguments in favor of garbage collection pretty compelling. Not having garbage collection has a big effect on your data structures. Instead of picking the data structure that makes your program the most efficient and easiest to understand, you pick one that makes memory management simpler. Managing memory by hand adds one more constraint to the design process, and the more it is constrained, the harder it gets.
david@cullsj.UUCP (David Taylor) (06/16/89)
In article <111@dbase.UUCP>, awd@dbase.UUCP (Alastair Dallas) writes: > In article <1989Jun13.084057.2032@LTH.Se>, newsuser@LTH.Se (LTH network news server) writes: > > > > I do not like the current ``discussion'' between Bertrand Meyer and > > Bjarne Stroustrup. I think it was wrong to start it, and I think... > > I disagree. Yes, no one else on the net has anything but opinion to add to > the discussion and the debate is more personal than factual. By some limited etc. I like this. An argument over whether to have arguments. Are we plagiarizing Monty Python sketches here?
ponce@chinet.chi.il.us (Lorenzo De Leon) (06/16/89)
From article <1989Jun13.084057.2032@LTH.Se>, by newsuser@LTH.Se (LTH network news server): > > I do not like the current ``discussion'' between Bertrand Meyer and > Bjarne Stroustrup. I think it was wrong to start it, and I think it I couldn't agree more. Please resume the continuing dialog on OOPLs and refrain from personal "discussions". Lorenzo De Leon Odesta Corp. Northbrook, Ill.
mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) (06/16/89)
In article <9438@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: =Bertrand Meyer, president of Interactive Software Engineering, the =supplier of Eiffel, is correct on one point: I did refuse to appear on =a panel with him. My reasons are personal. He has insulted my friends In article <5027@wiley.UUCP> simpson@poseidon.UUCP (Scott Simpson) writes: >This is censorship and this sucks. What nonsense! Too often, people think "censorship" means "the organizers/owners didn't let me give my point of view". Censorship involves a GOVERNMENT official who has the power to PENALIZE speech (etc.). The capitalized words are the important ones. Within extremely broad limits (such as slander, libel, national security), if I own a newspaper, or own a radio station, or set up a conference or party or discussion or debate, I can bloody well do whatever I want! If I set up a debate on, say, evolution, I don't have to invite creationists or evolutionists if I don't want to, or invite any particular person or set of people, because it's MY debate and I have control. "Freedom of the press belongs to the one who owns the press." Bjarne Stroustrup had a complete right to ask any conditions he wanted for appearance, from unconditional acceptance to unconditional refusal. Similarly for Bertrand Meyer. But it's OOPSLA's show, and they have the final right to say who will speak and how. Any negotiations are between the three of them. If a government official had intervened (say, idiotic fright about foreign nationals learning the secrets of object-oriented programming), THEN it would be censorship. >I would have kicked you [Stroustrup] off the panel. Perhaps. If I, the producer of a TV talk show, can have A or B but not both, I have to judge for myself which one I want. In the OOPSLA case, I'd want to find out: (a) if it is manifest that one of the two would contribute far more to the panel, (b) what kind of public insults, falsehoods, and out-of-context quotations Meyer has actually delivered or is likely to deliver. *IF* Stroustrup has demonstrated in previous conferences an effort to have technical discussions while Meyer has indulged in grossly unprofessional insults and misrepresentations, it would certainly tell very heavily against Meyer. *IF* these allegations are clearly true AND as serious as Stroustrup says, THEN it would be unfair to have Meyer on the panel. *IF* these allegations are clearly false or frivolous, it would be just as unfair to have Stroustrup on the panel. But I don't have any information to decide this case, and I suspect Scott Simpson doesn't either. If OOPSLA didn't have the information either, their behaviour was unjust. >Am I the only one who finds this behavior reprehensible? I certainly hope so! -- "Let me control a planet's oxygen supply, and I don't care who makes the laws." - GREAT CTHUHLU'S STARRY WISDOM BAND (via Roger Leroux) __ \ Tim, the Bizarre and Oddly-Dressed Enchanter \ mcdaniel@uicsrd.csrd.uiuc.edu /\ mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet} _/ \_ {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel
diamond@diamond.csl.sony.junet (Norman Diamond) (06/19/89)
In article <9438@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: >>>Bertrand Meyer, president of Interactive Software Engineering, the >>>supplier of Eiffel, is correct on one point: I did refuse to appear on >>>a panel with him. My reasons are personal. He has insulted my friends In article <5027@wiley.UUCP> simpson@poseidon.UUCP (Scott Simpson) writes: >>This is censorship and this sucks. >>I would have kicked you [Stroustrup] off the panel. In article <1265@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) writes: >What nonsense! Too often, people think "censorship" means "the >organizers/owners didn't let me give my point of view". Censorship >involves a GOVERNMENT official who has the power to PENALIZE speech >(etc.). The capitalized words are the important ones. >it's OOPSLA's show, and they have the final right to say who will speak and how. Time to poll the dictionaries on the precise meaning of "censorship" eh? Maybe we need an approximate synonym to describe what is happening. We aren't arguing semantics here because we all agree on what happened; but we're arguing the syntax of how to designate it. Anyway... Surely there are more people besides Bjarne Stroustrup who, having been offended by Bertrand Meyer's personality, would opt to kick themselves off a panel. They should be permitted to kick themselves off a panel. No one else should do the kicking. No one should have kicked Bertrand Meyer off the panel either. A professional, non-profit (tax assisted, indirectly), educationally oriented institution proposed a technical discussion for the edification of all. The proposed panelists all have some technical contributions and could (potentially) participate without degenerating into egotism or mudslinging. OOPSLA should not have kicked anyone off the panel *a priori*. When a participant exceeds the bounds of fair technical debate, it would be appropriate to remove him or her at that time. Each participant can decide whether, in order to avoid such embarrassment, to perhaps not participate. There are many reasons why possible participants might choose to exclude themselves. Unfortunately OOPSLA has chosen to take sides, display prejudice, and tar itself. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are claimed by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo, Stanford, or Anterior, then their administrators must have approved of these opinions.
jeff@aiai.uucp (Jeff Dalton) (06/19/89)
In article <150@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: >From article <2689@ssc-vax.UUCP> by dmg@ssc-vax.UUCP (David Geary): >Eiffel software is organized in autonomous software units (classes), >meant to be compiled separately. There is no main program. [...] In >contrast, I understand that C++ still follows the traditional C model. >[...] ``A C++ program typically consists of many source files, each >containing a sequence of declarations of types, functions, variables, >and constants''. This is very far from the object-oriented model of >software decomposition. It is true that C++ does not enforce object-oriented decomposition or provide explicit support for it. Nonetheless, a C++ programming environment could provide such support. And it is possible to make reasonable decompositions in C and C++, even though the compilation units are files, and even without any special environmental support that "hides the files". So I don't think C++ prevents the programmer from doing objet-oriented decomposition, but I'll have to leave the details to those who know more about C++ than I do. >Multiple inheritance > > Multiple inheritance is fundamental in the Eiffel approach. We made >every effort to handle it in a very clean way; name clashes, in particular, >are treated in what I believe is the right way. (More precisely, I do not >know of any satisfactory solution in any other language. This is a strong >statement, and proponents of other languages are welcome to respond to the >challenge.) I think the statement is too strong as it stands, because "satisfactory" isn't defined. It also makes it difficult for other languages to respond to the challenge. But I'm not sure it's possible to make strong conclusions in any case. Suppose someone said the Eiffel solution was unsatisfactory. How could this be resolved? IN the end you may just have different goals. >Garbage collection >As far as I know, C++ systems do not support garbage collection, >which would be extremely difficult if not impossible to implement >because of the presence of C types and mechanisms. As far as I know, it is possible to provide garbage collection for C, and some systems have actually done so. The GC has to be "conservative" in that it must regard anything that might be a pointer as a pointer. So there might be some garbage it can't collect, but it will never collect non-garbage. It is possible to write some things in C that will cause such systems to go wrong, but (again, as far as I know), all such things are regarded as nonportable. So conforming programs can't do them. -- Jeff
jeff@aiai.uucp (Jeff Dalton) (06/19/89)
In article <89155.092349UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >the address, and thus cannot optimize well. The same argument has >been made about strings---C does NOT have a string type. We fake it >with pointers (addresses) and arrays (pointers 8-). In a language >that does have a specific string data type, the compiler writer has >a chance to do some optimization tricks otherwise not available. I think this may be a more complex issue than it at first appears. Richard O'Keefe has argued on several occasions that string processing is more efficient when there isn't a built-in string type. I'm not sure he's correct, but he generally knows what he's talking about. (I'm sorry I don't have any "real" references -- there were just some articles in Comp.lang.c (I think) and Comp.lang.prolog.)
jimp@asterix.UUCP (Jim Patterson) (06/24/89)
In article <12031@nswitgould.OZ> geof@nswitgould.OZ (Geoffrey Jones) writes: >In article <129@eiffel.UUCP> Bertrand Meyer (bertrand@eiffel.UUCP) >follows up to provide a (patch) solution: > >> In version 2.2 the library class MEMORY will include an argumentless >> procedure called dispose, to be invoked by the garbage collector (if >> active) when an object is freed. > >The version 2.2 solution is indeed a step in the right direction but I >don't see that it should be the final answer. An "obvious" solution >might be to imbue Eiffel's `Forget' with an enlarged semantics, thus >moving the solution under the auspices of the language definition and >away from all the ad hoccery involving strange class inheritences. I >would propose that programmers could define their own `Forget' >routines analogously to programmer-defined `Create's. This suggestion ignores the significant difference between Eiffel's Forget builtin feature and more direct memory management primitives such as C's free. Forget simply clears a reference to an object; it's still left up to the garbage collector to actually free the object, and then only if there are not other references. If Forget were changed to actually dispose of the object (or to perform cleanup code), then other references to that object within the program would suddenly became invalid. This negates the major benefit of a garbage collector, which is to relieve the programmer of the burden of tracking which objects are or are not still accessable. Dispose is the more appropriate solution, as it supports an arbitrary number of references to any object so that the Dispose procedure is only actually called when there are no remaining references. One drawback is that the actual timing of a Dispose call is somewhat arbitrary; this must be considered when designing the class. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4
bertrand@eiffel.UUCP (Bertrand Meyer) (06/29/89)
From <233@pink.ACA.MCC.COM> rfg@pink.aca.mcc.com.UUCP (Ron Guilmette), quoted by later messages: >> For me, Eiffel was kind of like a chastity belt. It definitely keeps >> you "pure" but you will probably have less fun. >> It struck me, in fact, that a good many of [B. Meyer]'s comparisons between >> C++ and Eiffel boiled down to "C++ lets the programmer foul things up in >> any way he pleases, while Eiffel insists on doing it right". This is, in >> fact, a long-standing philosophical difference between the C camp and the >> Pascal camp. The debate, which is older and broader than the question of C versus Pascal, is indeed an important one: How restrictive and prescriptive may a language designer be in forcing a particular approach to software construction upon the users of the language? However their application to the design of Eiffel may be judged, I can at least clarify my intentions. 1. ``Chastity belts'' are inappropriate. A chastity belt prevents its holder from doing things that are desirable and enjoyable. A language designer is not a guardian of moral order. 2. A good programming language is one that helps programmers write good programs. No programming language will prevent its users from writing bad programs. [If I recall correctly, this is an observation I first heard a long time ago from Kees Koster, who among other things is the designer of the CDL language.] 3. Some constructs are known to be dangerous, meaning that programs employing them are prone to contain damaging errors. In any language meant for industrial production, it is the language designer's responsibility to exclude such constructs. Examples include type casts, user-controlled memory deallocation, pointer arithmetic, in-line functions (in an object-oriented language) etc. 4. The purpose of excluding a construct is not to prevent programmers from writing bad programs or doing ``dangerous things'' if they want to. (See points 1 and 2.) Instead, a construct is excluded because it is known to lead programmers to make mistakes even when applied towards legitimate goals. This highlights the basis for all this discussion. In the same way that the author of a novel has a typical reader in mind, the designer of a programming language is, consciously or not, designing for a typical programmer. We should assume (as was done for Eiffel) that this typical programmer is intelligent and reasonable. The restrictive parts of the language design are not meant to prevent the programmer from being ``bad'', but rather to help him avoid known pitfalls and involuntary mistakes. 5. For the language designer, excluding a construct is not a solution but a problem. In all likelihood the excluded construct addressed some legitimate need, albeit in an inadequate way. The designer must find a better technique to satisfy the same need. This is the difficult part, of course: exclusion is easy. Sometimes the solution is a better programming language construct; in other cases the problem is best handled by the implementation (compiler and programming environment). For example, unrestrained type casts may be replaced by inheritance-controlled polymorphism; garbage collection should be under the control of the run-time system; pointer arithmetic is unneeded in the presence of type-safe dynamic binding; and in-line routine expansion should be the responsibility of an optimizing compiler. 6. Literal compatibility with previous languages should not be a criterion. People will learn a new language quickly if its design is simple and consistent. One should learn from the mistakes of the past, not perpetuate them. Some care should be exercised, however, when one deals with programmers' current habits. For example, a new language should not use an existing notation in a way that confusingly departs from its accepted semantics. (The Eiffel assignment operator, :=, is a case in point; its semantics would probably have been different were it not for the fear of confusing Algol-Pascal-Ada programmers.) 7. Perhaps my major personal guideline is to maximize the signal-to-noise ratio of the language. Exclude constructs that just add complexity to the language without bringing any significant new possibility (for example, varieties of loops); include constructs that tersely and elegantly address a large number of practical situations. 8. Any occurrence in a language description of a sentence of the form ``Be careful when using this construct'' implying that its use may have dangerous consequences, is an avowal of failure on the designer's part. Programmers should be encouraged to use the entire language, not a subset. The programming language is the software developers' fundamental tool. They should know, love and trust all of it. 9. Hard as you try to maximize the signal-to-noise ratio, there may remain cases in which special needs require special facilities. Such special facilities should be limited to only one situation: the need to access low-level internal or machine-dependent elements. In my opinion, this is best addressed by techniques that fall outside of the language proper, such as machine-code insertions in Ada or external routines in Eiffel. To avoid violating the previous criterion (8), there should be very few such techniques, and they should never be needed in normal uses of the language. In Eiffel their typical uses have been encapsulated in the library (essentially in the class called INTERNAL) and their application is limited to the following cases: - Interfacing with elements on which the language design has no control: existing software tools (for example, relational data base management systems) or software written in other languages. - Machine-dependent programming. - Implementation of facilities which are part of the basic environment (such as the ARRAY and STRING classes in the kernel Eiffel library). - Facilities which the language designer feels are not necessary, while recognizing that some language users may disagree on this point. There is one example of this in Eiffel: class INTERNAL contains a procedure ``free'' which will explicitly return an object to the free store. In our opinion it should never be used, and none of our own software ever uses it; however we accept that some users may disagree and would rather provide the corresponding facility in an ``official'' form than encourage these users to fool around with internal formats. *** In summary, the aim of what Mr. Guilmette calls a more ``pure'' design is not to prevent programmers from ``fouling things up'' but to enable them to do things in a way that is at the same time safer, more elegant, more powerful and more convenient. Reconciling these goals is the main challenge in designing a better programming language. Coming back to the first two lines of his extract: >> For me, Eiffel was kind of like a chastity belt. It definitely keeps >> you "pure" but you will probably have less fun. Eiffel programmers can have fun, too, thank you. Of course, someone whose idea of fun is to spend his or her nights debugging will have less of it. But then such a person wouldn't need a chastity belt anyway. -- Bertrand Meyer bertrand@eiffel.com
nevin1@cbnewsc.ATT.COM (nevin.j.liber) (07/06/89)
Disclaimer: these are my PERSONAL opinions, period. I agree with some of the points; I am mainly commenting on those I disagree with. In article <166@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: |3. Some constructs are known to be dangerous, meaning that programs |employing them are prone to contain damaging errors. |In any language meant for industrial production, it is the language |designer's responsibility to exclude such constructs. | Examples include type casts, user-controlled memory deallocation, |pointer arithmetic, in-line functions (in an object-oriented language) |etc. Unfortunately, stuff like type casts and user-controlled memory management tend to be useful in many contexts. |4. The purpose of excluding a construct is not to prevent |programmers from writing bad programs or doing ``dangerous things'' if |they want to. (See points 1 and 2.) Instead, a construct is excluded |because it is known to lead programmers to make mistakes even when |applied towards legitimate goals. But, as a USER, I really don't care what the *purpose* behind doing something is. For example, the *purpose* behind putting in ramps in sidewalks wasn't to allow kids to ride their bicycles into traffic without having to stop like they had to for curbs, yet that was the *result*. |The restrictive parts of the language design are not meant to prevent |the programmer from being ``bad'', but rather to help him avoid |known pitfalls and involuntary mistakes. But they DO prevent the programmer from being ``bad''; that is the price that is being paid in order to help him avoid known pitfalls and involuntary mistakes. |6. Literal compatibility with previous languages should not be a |criterion. People will learn a new language quickly if its design is |simple and consistent. One should learn from the mistakes of the past, not |perpetuate them. | Some care should be exercised, however, when one deals with programmers' |current habits. For example, a new language should not use an existing |notation in a way that confusingly departs from its accepted semantics. |(The Eiffel assignment operator, :=, is a case in point; |its semantics would probably have been different were it not for the fear |of confusing Algol-Pascal-Ada programmers.) Keeping 6 in mind, and assuming that you wanted to give the Eiffel assignment operator different semantics than those given by Algol/Pascal/Ada to ":=", why didn't you just pick another symbol (eg: ".=")? Please elaborate. |7. Perhaps my major personal guideline is to maximize the signal-to-noise |ratio of the language. | Exclude constructs that just add complexity to the language without |bringing any significant new possibility (for example, varieties of |loops); include constructs that tersely and elegantly address a large number |of practical situations. But varieties of loops, if used correctly (admittedly, a big if), can add to the self-documenting aspect of a language. This whole discussion reminds me of an early paper by Wirth which I read a while back (I wish I could find that paper :-(). In it, he spends the first half describing his ideal programming language, which, to me, seemed close to C, and then spent the second half saying that it was unusable because you couldn't guarantee safety. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
bertrand@eiffel.UUCP (Bertrand Meyer) (07/07/89)
From <1559@cbnewsc.ATT.COM> by nevin1@cbnewsc.ATT.COM (nevin.j.liber): [Quoting from my previous message: ] > | Some care should be exercised, however, when one deals with programmers' > |current habits. For example, a new language should not use an existing > |notation in a way that confusingly departs from its accepted semantics. > |(The Eiffel assignment operator, :=, is a case in point; > |its semantics would probably have been different were it not for the fear > |of confusing Algol-Pascal-Ada programmers.) > [...] Assuming that you wanted to give the Eiffel > assignment operator different semantics than those given by > Algol/Pascal/Ada to ":=", why didn't you just pick another symbol (eg: > ".=")? Please elaborate. [Perhaps :-) would do for assignment?] :-) Actually the Eiffel convention is the same as the Pascal and Ada ones for entities of pointer/access/reference types, which is the reason for keeping the same notation. In general it seems proper to avoid inventing a new notation where there is no real semantic innovation and a widely accepted notation exists, unless there are strong arguments against that notation. (An example of the latter would be the Fortran/C use of = for assignment, which conflicts with time-honored mathematical conventions.) The language should look familiar in places where the concepts are indeed familiar. There are a number of novel ideas in Eiffel, but assignment is a quite standard concept. As one may expect, the properties of assignment in Eiffel are not identical to those of its counterparts in previous languages, but the differences do not seem big enough to warrant a totally new notation. Call it lack of courage if you will. -- Bertrand Meyer bertrand@eiffel.com
pcg@thor.cs.aber.ac.uk (Piercarlo Grandi) (07/09/89)
In article <168@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: From <1559@cbnewsc.ATT.COM> by nevin1@cbnewsc.ATT.COM (nevin.j.liber): > [...] Assuming that you wanted to give the Eiffel > assignment operator different semantics than those given by > Algol/Pascal/Ada to ":=", why didn't you just pick another symbol (eg: > ".=")? Please elaborate. [Perhaps :-) would do for assignment?] :-) Remember this line for later on... Actually the Eiffel convention is the same as the Pascal and Ada ones for entities of pointer/access/reference types, which is the reason for keeping the same notation. Ugh. I beg to differ. Pascal and Ada have a concept of pointer, and indeed := is used by them to do *copy* of pointer objects. This is VERY different from Eiffel. The analogy cannot hold. In general it seems proper to avoid inventing a new notation where there is no real semantic innovation and a widely accepted notation exists, unless there are strong arguments against that notation. Eiffel, by doing without a concept of pointer (except by hack) and by having reference and copy assignments both under := blurs the distinction between EQ and EQUAL, that lispers know as being very fundamental. As one may expect, the properties of assignment in Eiffel are not identical to those of its counterparts in previous languages, but the differences do not seem big enough to warrant a totally new notation. Call it lack of courage if you will. Ahhh! Let me exhume old ghosts... Simula67 uses := for assignment, and :- for reference assignment. You would have invented nothing new, and adopted a well known tradition, if you had used :- for reference (in the Simula67 sense) assignment. Also, I am incredibly amused by the idea that actually :- *is* the leading part of :-)... NOTE: I find it worrying that the author of Eiffel, a person that I greatly esteem, is not extremely familiar with Simula67 and Lisp. Now some embarassing questions: Has he ever read the Simula67 Common Base standard? Simula BEGIN? What is Hash Consing and how does it relate to this discussion? What is rplac[ad] and how does it relate to this discussion? NOTE on NOTE: many will have noted (:->) that one of my pet peeves is moaning about the lack of historical perspective by most computer scientists (especially, let me say, American (ised :->) ones wrt much European research). I apologise in advance for the irritation this mania causes... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
bertrand@eiffel.UUCP (Bertrand Meyer) (07/10/89)
From article <PCG.89Jul8222705@thor.cs.aber.ac.uk>, by pcg@thor.cs.aber.ac.uk: > Pascal and Ada have a concept of pointer, > and indeed := is used by them to do *copy* of pointer objects. This > is VERY different from Eiffel. Unless there is something I don't understand I am afraid Mr. Grandi is mistaken. Both in Pascal and in Ada := is used for pointer assignment. For Pascal, see chapter 10 of Pascal User Manual by Kathleen Jensen and Niklaus Wirth, Springer-Verlag, 1974 (pages 62-66 in the second edition); also the ``Report'' part of the same book, section 7.3. For Ada, the relevant section of the Reference Manual (3.8) is not the most luminous piece of technical literature ever written, but there is no doubt that the semantics is indeed that of pointer assignment. (See for example ``Ada for Experienced Programmers'' by A. Nico Habermann and Dewayne E. Perry, Addison-Wesley, 1983, page 197.) Interestingly enough, Pascal and Ada both also use := to prescribe value assignment for referenced records. I believe the correct notations are p^ := q^ in Pascal and p.all := q.all in Ada. As explained in my article on ``Eiffel types'', there are cases in which one *explicitly wants* to have the same symbol express different semantics for reference types and expanded types. (The latter is Eiffel 2.2 terminology for types whose elements are objects rather than references to objects; expanded types include the basic types INTEGER, REAL, DOUBLE etc.) Thanks to expanded types and the associated assignment and argument passing conventions, Eiffel 2.2 allows programmers to choose exactly what they need in a given case: uniform copy semantics, or variable semantics. This is particularly important for generic classes. > I find it worrying that the author of Eiffel [...] > is not extremely familiar with Simula67 and Lisp. > Now some embar[r]assing questions: Has he ever read the Simula67 > Common Base standard? Simula BEGIN? What is Hash Consing and how > does it relate to this discussion? What is rplac[ad] and how does > it relate to this discussion? > This is an interesting idea: Usenet as an ongoing certification program, or people's tribunal (``You don't even know the basics!'', shouts the Red Guard to the Mandarin). It is tempting to reply, as Mitterrand to Giscard d'Estaing during the 1981 presidential debate, ``I am not your student, and you are not my professor'', but let me not be stuffy and indeed answer. The author of Eiffel did write more than a few Lisp and Simula programs, thank you. One of my first programming courses was a Lisp course taught by Prof. John McCarthy; I remember him as reasonably competent on the subject. On Simula, please see ``Quelques concepts importants des langages de programmation modernes, et leur expression en Simula 67'', by the undersigned, GROPLAN 9, AFCET, 1979. (English version presented at the Tenth Conference of the Association of Simula Users, Oslo, in, I believe, 1980 or 1981.) As to rplaca and rplacd, the definition I am tempted to give is ``If you like the idea of functional programming, the main arguments for using Miranda rather than Lisp''. -- Bertrand Meyer bertrand@eiffel.com