tombre@crin.fr (Karl Tombre) (03/01/90)
In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: From <Ec.3251@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > Personally, it's the little things like this that make me > believe that everyone should ABANDON C and move on to C++(two others being > function prototyping and strong type checking). Waddya think? Wither C? How can the words ``strong type checking'' be applied to a language in which any variable may be cast to any type? In which you declare the type of a generic list element to be ``pointer to characters''? C++ only magnifies the problems of C, and it does not even have the excuses that can be invoked in the case of a 20-year old design such as C. [and so on] Am I the only one having regularly the following problem? I think Eiffel is a very good language (probably one of the best), I am quite impressed by its design. I also appreciate Bertrand Meyer's various technical and scientifical contributions in conferences and newsgroups. But from time to time, this attitude of his comes up and annoys me VERY MUCH : he seems to have difficulties accepting that there are other solutions for object-oriented programming, that other languages exist and are popular for various reasons. He especially tends to become "rabid" when speaking of C++. This leaves such a bad "taste in my mouth" that it tends to give me unjustly biased views of Mr. Meyer's product, i.e. Eiffel. That any "neutral" user gives his opinion about the merits or deficiencies of C++, Eiffel, Smalltalk, Cobol, BASIC or whatever is just fine. But shouldn't it be plain decency to restrain from commenting in such strong and passionnate terms about one's concurrents' products ? Especially for somebody wishing not to be a marketing person but to be known as an authority in OO languages and design ? I remember for instance reading some time ago, in the news, comments from either Brad Cox or Bjarne Stroustrup about the other's language; at no time did it have such a bad taste than the referenced article. Isn't it on the border of arrogance to believe that "I know the definite, final and only TRUTH about how an object-oriented language should be designed" ??? -- Karl Tombre - INRIA Lorraine / CRIN EMAIL : tombre@loria.crin.fr - POST : BP 239, 54506 VANDOEUVRE CEDEX, France
bertrand@eiffel.UUCP (Bertrand Meyer) (03/01/90)
From <Ec.3251@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > Personally, it's the little things like this that make me > believe that everyone should ABANDON C and move on to C++(two others being > function prototyping and strong type checking). Waddya think? Wither C? How can the words ``strong type checking'' be applied to a language in which any variable may be cast to any type? In which you declare the type of a generic list element to be ``pointer to characters''? C++ only magnifies the problems of C, and it does not even have the excuses that can be invoked in the case of a 20-year old design such as C. All the flaws of the older language are still there; amount countless examples, the break and switch instructions, which were purportedly responsible for the AT&T breakdown (and started this whole discussion) are still there exactly as in C. The bug would have occurred identically. Then there are new complexities and major new trouble spots - such as default static binding, which means the guarantee that the *incorrect* version of an operation will be applied! -- Bertrand Meyer bertrand@eiffel.com
henry@utzoo.uucp (Henry Spencer) (03/02/90)
In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: >> Personally, it's the little things like this that make me >> believe that everyone should ABANDON C and move on to C++(two others being >> function prototyping and strong type checking)... > > How can the words ``strong type checking'' be applied to a language >in which any variable may be cast to any type? In which you declare the >type of a generic list element to be ``pointer to characters''? Come now, at least criticize the modern language, not a caricature of what you think it was fifteen years ago. Many "systems programming" languages allow deliberate unsafe type conversions if you request them, and they are not considered any less "strongly typed" for it. Modern C is a strongly-typed language by any reasonable definition, although there are still a lot of antique compilers around that don't fully enforce its rules. (NB you can't cast any variable to any type in C, only certain combinations are valid.) And any modern generic pointer declaration will say `void *' not `char *'. There are enough real problems with C and C++ without making up silly strawmen. (P.S. They remain eminently usable languages for people who know what they're doing, although incompetents and novices should definitely avoid them. Alas, all too many of the "real programs" in the world are written by incompetents and novices...) -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
nick@lfcs.ed.ac.uk (Nick Rothwell) (03/02/90)
In article <1990Mar1.172526.28683@utzoo.uucp>, henry@utzoo (Henry Spencer) writes: >Modern >C is a strongly-typed language by any reasonable definition, Could you give me a reference to the type semantics? Nick. Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ A prop? ...or wings? A prop? ...or wings? A prop?
feg@clyde.ATT.COM (Forrest Gehrke,2C-119,7239,ATTBL) (03/02/90)
In article <1990Mar1.172526.28683@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > > There are enough real problems with C and C++ without making up silly > strawmen. > > (P.S. They remain eminently usable languages for people who know what > they're doing, although incompetents and novices should definitely > avoid them. Alas, all too many of the "real programs" in the world are > written by incompetents and novices...) While I agree 100% with everything you said in this article in support of the modern C language, aren't you being a little contradictory in your postscript? Unless you anticipated Dennis Ritchie, one day you too were a novice in C. Fortunately you didn't avoid it. (;-)) Forrest Gehrke feg@clyde.ATT.COM
karl@haddock.ima.isc.com (Karl Heuer) (03/03/90)
In article <1004@micropen> dave@micropen (David F. Carlson) writes: >What break does is *very* well defined and is no more prone to >misinterpretation that any other non-linear control flow statement ... Yes, it's well defined, but what it's defined to do is bad. For a formal treatment of the above statement, I refer you to my article <16039@haddock.ima.isc.com>, posted to comp.lang.misc (also .c and .ada) with this same title. I haven't seen any rebuttals yet. >A multi-case switch is very handy in many situations ... Yeah. I wish C had this feature, instead of simulating it with fallthrough. >That you ask the question of the usefulness of break-per-case/multiple-cases >implies that you haven't sufficient experience with the construct to judge >its merits/weaknesses. I don't know about the person you were addressing, but I think I've had sufficient experience with it. I certainly question its usefulness in comparison to something reasonable, like the language I described in my other article. In fact, even if you insist that the comparison must be between C and plain-C-without-break-switch, I think I'd still go for the latter. I believe the benefit of not requiring an overloaded keyword to do a break-switch exceeds the cost of having to use a goto to merge related cases. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
dan@charyb.COM (Dan Mick) (03/03/90)
In article <TOMBRE.90Mar1013132@weissenburger.crin.fr| tombre@crin.fr (Karl Tombre) writes: |In article <259@eiffel.UUCP| bertrand@eiffel.UUCP (Bertrand Meyer) writes: | From <Ec.3251@cs.psu.edu| by melling@cs.psu.edu (Michael D Mellinger): | | | Personally, it's the little things like this that make me | | believe that everyone should ABANDON C and move on to C++(two others being | | function prototyping and strong type checking). Waddya think? Wither C? | | How can the words ``strong type checking'' be applied to a language | in which any variable may be cast to any type? In which you declare the | type of a generic list element to be ``pointer to characters''? | | C++ only magnifies the problems of C, and it does not even have the | excuses that can be invoked in the case of a 20-year old design such as C. | [and so on] | |Am I the only one having regularly the following problem? No. |I think Eiffel is a very good language (probably one of the best), I |am quite impressed by its design. I also appreciate Bertrand Meyer's |various technical and scientifical contributions in conferences and |newsgroups. But from time to time, this attitude of his comes up and |annoys me VERY MUCH : he seems to have difficulties accepting that |there are other solutions for object-oriented programming, that other |languages exist and are popular for various reasons. He especially |tends to become "rabid" when speaking of C++. This leaves such a bad |"taste in my mouth" that it tends to give me unjustly biased views of |Mr. Meyer's product, i.e. Eiffel. I know nothing *at all* about Eiffel, and I'm much less encouraged to learn about it based on Bertrand's comments. It's not that I'm less interested in it technically; it's just that, due to his attitude toward communication in general, I'm less apt to believe anything he's done technically is useful. |That any "neutral" user gives his opinion about the merits or |deficiencies of C++, Eiffel, Smalltalk, Cobol, BASIC or whatever is |just fine. But shouldn't it be plain decency to restrain from |commenting in such strong and passionnate terms about one's |concurrents' products ? Especially for somebody wishing not to be |a marketing person but to be known as an authority in OO languages and |design ? I remember for instance reading some time ago, in the news, |comments from either Brad Cox or Bjarne Stroustrup about the other's |language; at no time did it have such a bad taste than the referenced |article. Isn't it on the border of arrogance to believe that "I know |the definite, final and only TRUTH about how an object-oriented |language should be designed" ??? Yes. Yes, it should. Unfortunately, the world is run by sales slime. Good luck telling the difference.
henry@utzoo.uucp (Henry Spencer) (03/03/90)
In article <2568@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >>Modern >>C is a strongly-typed language by any reasonable definition, > >Could you give me a reference to the type semantics? ANSI X3.159 (I think that's the correct number) defines all the semantics of C. Publication is imminent. "Strongly typed" and "has a mathematically formal definition of type semantics" are two entirely different concepts, in case the latter was what you were thinking of. As far as I know, nobody has yet produced a formal definition of C. It is possible, although painful, to formally define non-strongly-typed languages. -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (03/04/90)
In article <4397@cbnewsl.ATT.COM> feg@clyde.ATT.COM writes: >> ([C/C++] remain eminently usable languages for people who know what >> they're doing, although incompetents and novices should definitely >> avoid them. Alas, all too many of the "real programs" in the world are >> written by incompetents and novices...) > >While I agree 100% with everything you said in this article in >support of the modern C language, aren't you being a little >contradictory in your postscript? Unless you anticipated >Dennis Ritchie, one day you too were a novice in C. Fortunately >you didn't avoid it. (;-)) I should have drawn slightly finer distinctions here. Programming novices should avoid C, period. Experienced programmers who are C novices should use C cautiously and avoid using it for production software, if possible, until they're used to it. Incompetents should go somewhere where their lack of talent will not be noticed, e.g. the local DoD contractor. :-) (It's no accident that one big push for languages that try to legislate competence comes from DoD...) Yeah, I was a C novice once. I'm glad that all the code I wrote then is dead and buried. -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
g2k@mentor.cc.purdue.edu (Frederic Giacometti) (03/05/90)
In article <TOMBRE.90Mar1013132@weissenburger.crin.fr> tombre@crin.fr (Karl Tombre) writes: >In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: > From <Ec.3251@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > > > Personally, it's the little things like this that make me > > believe that everyone should ABANDON C and move on to C++(two others being > > function prototyping and strong type checking). Waddya think? Wither C? > > How can the words ``strong type checking'' be applied to a language > in which any variable may be cast to any type? In which you declare the > type of a generic list element to be ``pointer to characters''? > > C++ only magnifies the problems of C, and it does not even have the > excuses that can be invoked in the case of a 20-year old design such as C. > [and so on] > >Am I the only one having regularly the following problem? > .......... >article. Isn't it on the border of arrogance to believe that "I know >the definite, final and only TRUTH about how an object-oriented >language should be designed" ??? > Firstly, let me clear up my position on the C/C++ problem: I agree completely with B. Meyer on C/C++. Is it being arrogant than saying that C++ is no more than a bricolage around C when it is the mere truth ? B. Meyer, may strongly cast his opinions, sometimes subtility is the mark of a good mind, but there are other marks as much valuable, among which are frankness and clarity of one's opinion. Secondly, a cultural problem has to be addressed. I am surprised to see this article emitted from a site in France; that person should know that "every frenchman is arrogant" (one of the most common image of French in america: lover and arrogant). This net is not the place to discuss these features of French culture and education which make that Frecnh intellectual life is particularly animated and opiniated (a feature one also finds in Quebeccan politics), a severe contrast with the blendness of anglo-saxon puritan life. By looking at his first name, I shall consider that Karl must not be french. Thirdly, I admire the courage of B. Meyer who successfully started his own independent business. What he is doing is unique in the annals of computer science: to center the development of a new company around the development of a language. And I assert that it is a certificate of quality about the language. As example of low techinical quality products which were commercially successfull because of a name, one can quote the IBM PC line. If you look at the history of computer science, major developments (Apple is the exception) have usually been produced by major corporations rather than by motivated individuals. This dynamism derives from a strong personality (another arrogant man of which we recently heard of was Steve Jobs with his NeXT machines). At least B. Meyer engages the discussion and takes position on problems, whatever it be. He does not hide himself beyond some obscur corporate barrier. Discussions on the net are technical, not commercial. Meyer exposes his technical point of view, not more. Until now, I haven't seen many flaws in his analyzes; if so let me know. His position has the merit of the clarity. One only has to know it. So far, C++ has taken up not much because of its intrinsic value, but because of the support of AT&T. Besides the problems specific to C, it is not even a complete object-oriented language (where is the dynamic binding ?). The compatibility with C is more or less its only advantage from a technical point of view. When he designed the language, Stroustrup grabbed some ideas from Modula, and put some inheritance paradigm. On top of that, the american press, hearing the name AT&T, rushed into it. Bof, it may convince the one who like to follow the masses. In that case, it is sure that the voice of Meyer is very unpleasant, it disturbes what one wants to hear: the mass is right and secure. I maintain that, although for programmers who know C, C++ is the seducing solution, C++ has exceedingly weak theoretical bases to justify its use in the future. Should this be considered as arrogance ? Eiffel has a very strong theoretical and formal support. It is the product of a rigorous approach. All the contrary of C++, of which approach is pragmatic, aimed at solving a short term industrial problem: how to improve C without throwing it away. Well, it is with such raisonning that america is still using the english system of measures, and other degree Farenheit, to the great pleasure of the future generations and technological progress of america. Frederic Giacometti School of Industrial Engineering Purdue University
ok@goanna.oz.au (Richard O'keefe) (03/05/90)
In article <8113@mentor.cc.purdue.edu>, g2k@mentor.cc.purdue.edu (Frederic Giacometti) writes: > Firstly, let me clear up my position on the C/C++ problem: I agree > completely with B. Meyer on C/C++. Is it being arrogant to say > that C++ is no more than a bricolage around C when it is the mere truth ? I'm about to pick a nit, so I'll start by saying that -- I found a year's course on category theory easier to understand than C++. I used to read comp.lang.c++ but was frightened off. -- the ISE compiler for Eiffel generates C as its output -- I would be very happy if Eiffel outsold C++ -- Eiffel has no published formal definition *either*. > Thirdly, I admire the courage of B. Meyer who successfully started his > own independent business. What he is doing is unique in the annals of > computer science: to centre the development of a new company around the > development of a language. This is hardly unique. What about Objective-C? What about the Edinburgh team that developed Edinburgh Prolog and then founded Quintus? What about the earlier attempt (that failed) to build a small company around Pop? What about ParcPlace? There are lots more examples... > And I assert that it is a certificate of quality about the language. No. All that it certifies is that (a) the founders of the company believed in the language and that (b) they were about to persuade a moneylender that the company was a good risk. > If you look at the history of computer science, > major developments (Apple is the exception) have usually been produced > by major corporations rather than by motivated individuals. It is not clear that this is the case. (1) In many cases developments are _initiated_ by motivated individuals and taken over by corporations. (2) In many other cases, developments are brought about by motivated individuals _within_ major corporations. Not everything that a corporation does is initiated by the board of directors! For example, IBM didn't really want to get into computers in the first place; the man who wanted them to do so had to go out and get orders for the machines *first* before T.J.Watson could be persuaded. > So far, C++ has taken up not much because of its intrinsic value, but > because of the support of AT&T. Is this really true? In day to day terms, what does "the support of AT&T" amount to? It doesn't mean rapid bug fixes. I was under the impression that the great appeal of C++ was that you could move into it gradually, starting out just using it as a better C compiler and learning the extra features one by one, never having the sensation of learning a whole new language. Really good programmers are not afraid of learning a whole new language, and will do it if they have reason to believe it will pay off. There are lots of programmers who are reluctant to change. > Eiffel has a very strong theoretical and formal support. It is the > product of a rigorous approach. If there is a formal specification of Eiffel (version 2.2 for choice) I would very much like to see it. "Eiffel: The Language" says quite clearly (section 2.3) "This book is not a "formal" description of Eiffel". Alas, it's as close as we get.
shap@delrey.sgi.com (Jonathan Shapiro) (03/05/90)
In article <418@charyb.COM> dan@charyb.UUCP (Dan Mick) writes: >|[... re Bertrand Meyers] He especially >|tends to become "rabid" when speaking of C++. This leaves such a bad >|"taste in my mouth" that it tends to give me unjustly biased views of >|Mr. Meyer's product, i.e. Eiffel. > >I know nothing *at all* about Eiffel, and I'm much less encouraged to learn >about it based on Bertrand's comments. I know a little bit about Eiffel and have read quite a numbet of Bertrand's technical "contributions" to the world. I have known Bertrand to be charming. I have also known him to be rabid. Consider, for a moment, how you would act after so many years of uphill battles against languages like C++ that are deficient in some important ways. Having read many of his papers, however, and examined the design of Eiffel in some detail, I am obliged to conclude that Eiffel is not nearly as elegant as the marketing hype would have you believe, and that Bertrand is in general not an effective communicator. Whatever might be true about Bertrand himself, Bertrand's papers convinced me long ago not to take Eiffel seriously. Eiffel has a few good ideas cribbed from some earlier languages. It ain't the worlds ultimate programming language. Jonathan Shapiro
tat@pccuts.pcc.amdahl.com (Tom Thackrey) (03/06/90)
In article <1990Mar4.005122.14121@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >I should have drawn slightly finer distinctions here. Programming novices >should avoid C, period. Experienced programmers who are C novices should >use C cautiously and avoid using it for production software, if possible, >until they're used to it. Incompetents should go somewhere where their >lack of talent will not be noticed, e.g. the local DoD contractor. :-) >(It's no accident that one big push for languages that try to legislate >competence comes from DoD...) Why is it necessary to slander some group or another to make a point? BTW If they didn't notice why would they push ...? -- Tom Thackrey sun!amdahl!tat00 [ The opinions expressed herin are mine alone. ]
bruce@menkar.gsfc.nasa.gov (Bruce Mount 572-8408) (03/06/90)
At the risk of losing my anonymity, I'm jumping feet first into the Eiffel Jihad. Along with working full time as a contractor to NASA, I am the teaching assistant for the "Object Oriented Programming" class at the nearby University of Maryland. Dr. Meyer's contribution to computer science by designing Eiffel is tremendous. Eiffel is the most elegant OOP language available today. It's elegance allows the programmer to easily understand the entire language in a short period of time while giving them unmatched control via assertions and sensible exception handling. This is, of course, my opinion, but one that can be supported by numerous rigorous arguments. In my (limited) personal experience, every single person I know that has access to both Eiffel and C++ uses Eiffel. However, my opinions about Eiffel are not the point. Rather, I would like to discuss Dr. Meyer's attitude. Dr. Meyer has the quite normal feeling that his language is the best OOP available. If he didn't feel that there were problems with C++, Objective-C, etc. he wouldn't have designed Eiffel in the first place. I'm sure that Brad Cox and Bjarne Stroustrup have similar feeling about their languages. The difference, however, is that Dr. Meyer has the courage of his convictions to debate them in public. People who read comp.lang.eiffel regularly see posting from Dr. Meyer debating various aspects of the language. These are, in fact, *debates* NOT arguments, and I have seen Dr. Meyer post articles several times that said "Ignore my previous posting, I was wrong and John Doe was right". I have heard stories from OOPSLA that Bjarne Stroustrup refused to sit on the same panel with Dr. Meyer because Dr. Meyer was too critical of C++. I have heard this story from several different sources, but I still hope that it is not true. If OOPSLA is not the correct place to debate the various languages then where is? The fact that Dr. Meyer feels strongly about the OOP paradigm can only be helpful to the entire field. Dr. Meyer generally makes his points in a clear, rigorous, manner. People from all religions (C++, Objective-C,...) should try to listen to his points with an ear towards how they could apply his ideas to their languages. I would be delighted to listen to Brad Cox or Bjarne Stroustrup, it only they would participate in network discussions. -Bruce ================================================= | Bruce Mount "Brevity is best" | | bruce@atria.gsfc.nasa.gov | =================================================
henry@utzoo.uucp (Henry Spencer) (03/07/90)
In article <885@pccuts.pcc.amdahl.com> tat@pccuts.pcc.amdahl.com (Tom Thackrey) writes: > >... Incompetents should go somewhere where their > >lack of talent will not be noticed, e.g. the local DoD contractor. :-) > >(It's no accident that one big push for languages that try to legislate > >competence comes from DoD...) >Why is it necessary to slander some group or another to make a point? Not necessary, just fun. :-) Also verifiably true, I'm afraid, which is generally considered adequate defence against charges of slander... (This is not to say that there aren't some good software people working for some DoD contractors, just that the average is very low.) >BTW If they didn't notice why would they push ...? Oh, they notice, but they keep signing contracts with the same people anyway. They want a technical solution, not something simple and obvious like paying enough to attract competent people and then refusing to buy from incompetents. -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (03/09/90)
In article <TOMBRE.90Mar1013132@weissenburger.crin.fr> tombre@crin.fr (Karl Tombre) writes: >In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: > From <Ec.3251@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger): > > > Personally, it's the little things like this that make me > > believe that everyone should ABANDON C and move on to C++(two others being > > function prototyping and strong type checking). Waddya think? Wither C? > > How can the words ``strong type checking'' be applied to a language ^^^^^^^^^^^^^^^^^^^^ > in which any variable may be cast to any type? In which you declare the > type of a generic list element to be ``pointer to characters''? > > C++ only magnifies the problems of C, and it does not even have the > excuses that can be invoked in the case of a 20-year old design such as C. > [and so on] > >Am I the only one having regularly the following problem? > > [...] But from time to time, this attitude of his comes up and >annoys me VERY MUCH : he seems to have difficulties accepting that >there are other solutions for object-oriented programming, that other ^^^^^^^^^^^^^^^ >languages exist and are popular for various reasons. He especially >tends to become "rabid" when speaking of C++. [...] Perhaps you ought to *read* what you quote. It seems to me *you* are the one with the attitude problem. Mr. Meyer stated one explicite objection - that C++ cannot be said to have 'strong type checking'. He also stated one general observation - that C++ magnifies the problems of C. He made no comments regarding any of the object-oriented features. Since the thread is about the "robustness" of languages, and Mr. Mellinger suggested C++ for its strong type checking, I think it is entirely fair for Mr. Meyer to comment on this topic. If you disagree with Mr. Meyer, feel free to post why you think C++ does have strong type checking. Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 Me? Represent other people? Don't make them laugh so hard.
jimad@microsoft.UUCP (Jim ADCOCK) (03/09/90)
In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: [Not totally without cause, IMHO] > How can the words ``strong type checking'' be applied to a language >in which any variable may be cast to any type? How can the words 'strong type checking' be applied to a language that gets its permissions on return types exactly backasswards? Fix your *own* language, before throwing stones, Bertrand! In C++ not any variable can be cast to any type, although many questionable casts are allowed *if specifically called for by the programmer* In this light C++ follows the C lead of assuming the programmer is a mature adult who can make his/her own decisions on these things. Other languages don't *really* prohibit programmers from doing these things where the programmer desires -- if worse comes to worse, the programmer just breaks out the old assembly language, and does what is necessary to get the job done. A problem C++ has is that the C++ community has a large number of old C hackers who run fast and loose with their coercions, and then find that in C++ these hacks tend to bite them. But, at least C++ *has* this large community of old C hackers. [Not to use the term "hacker" in a totally derogatory sense] The biggest problem [IMHO] is the continued heavy dependence by many C++ programmers/implementations on the C Pre Processor -- which allows for textual substitutions to text code before the code even gets to the C++ compiler. Not only is the C Pre Processor totally *not* type safe, it also allows programmer to make all kinds of hacks to the [apparent] syntax of their code. Further, the C Pre- Processor makes simple tasks, such as the correct importing/exporting of definitions a real nuisance. >In which you declare the type of a generic list element to be >``pointer to characters''? C++ provides "C" primitives like "pointer to char" that programmers can use to create their own well encapsulated higher-level classes such as "String." Other OOPL languages, such as Eiffel, do not provide this low level support. Instead, the authors of these other languages break out their handy-dandy "C" compiler and program up *one* version of a "String" class that *all* users of the language must use -- even if it doesn't make the optimal speed/space/complexity tradeoffs for that a particular user needs. This heavy dependence on standard libraries to do everything tends to mean that OOPLs taking this approach only come from one vendor. Better to provide compilers and libraries separately, and allow users to choose which from where best meet their needs. C++ attempts to provide the power and flexibility to cover the entire spectrum of programming tasks users need to do. This includes the power and flexibility to hose yourself, if you insist on doing so. > C++ only magnifies the problems of C, and it does not even have the >excuses that can be invoked in the case of a 20-year old design such as C. I am somewhat sympathetic to this complaint. The latest definitions of C++ try to be backwardly compatible with K&R C, ANSI-C, and previous versions of C++. In some areas, this makes for some pretty complicated language rules. This makes the life of compiler writers harder, so that users can write C/C++ code as they are use to writing, and most of the time their software will compile without compiler squawks. Personally, I think it would be good to give up some of the backward compatibility in order to clean up some of the language rules. Perhaps this will happen as part of the ANSI-C++ standardization effort. In any case, it will be nice to have a standardize OOP language. >All the flaws of the older language are still there; amount countless >examples, the break and switch instructions, which were purportedly >responsible for the AT&T breakdown (and started this whole discussion) >are still there exactly as in C. The bug would have occurred identically. C++ OOP programmers avoid switch statements as not being "object oriented," so propagating this "C" bogosity to C++ is not much of a problem. Compilers can choose to warn against missing break statement, if the compiler writers so choose. Better yet, an OOPL compiler should warn against using switch statements in the first place! > Then there are new complexities and major new trouble spots - >such as default static binding, which means the guarantee that the >*incorrect* version of an operation will be applied! I disagree. If a programmer wants a member function to answer to a particular abstract protocol, the programmer creates such an abstract protocol, marking its member functions "virtual", and inherits the protocol in concrete classes matching that protocol. Member functions in those concrete classes that match the abstract protocol are automatically default dynamic binding. The "default static binding" you mention keeps classes with method names that *accidentally* match the names of parts of protocols from being considered such. This prevents the problem common in other OOPLs where method names accidentally match, causing problems not detected [if ever] until run time. As always, the proof is in the pudding. I encourage people new to OOP to actually *try* several languages in "non-trivial" tasks, and see how well those languages, and their compilers, meet you needs. Your smilage will vary. [Standard disclaimer, these are *my* opinions only. I do not disagree with Bertrand entirely, only in degree.]
bertrand@eiffel.UUCP (Bertrand Meyer) (03/09/90)
From <2628@castle.ed.ac.uk> by nick@lfcs.ed.ac.uk (Nick Rothwell): > The [Eiffel] type system seems a bit shakey to me. From <53012@microsoft.UUCP> by jimad@microsoft.UUCP (Jim ADCOCK): > How can the words 'strong type checking' be applied to a language > [i.e. Eiffel] that gets its permissions on return types exactly > backasswards? Fix your *own* language, before throwing stones, Bertrand! Every once in a while someone ``discovers'' that the Eiffel type system is ``wrong''. The latest printed occurrence I know of is a letter published in the last JOOP. The Eiffel type system is neither ``shakey'' nor wrong. I have written a long paper (posted in comp.lang.eiffel as <176@eiffel.UUCP> and <177@eiffel.UUCP> in July of 1989) explaining why the type rules are what they are. This answered in particular an earlier paper by William Cook. My paper has not been published in print (for lack of time and because I will reuse it as book chapter), but it has been fairly widely circulated since it was first posted. Denying the validity of Mr. Rothwell's statement would be contradicting a matter on which he is better informed than I am: his personal opinion regarding the Eiffel type system. There is no reason to doubt that the statement is true, although it provides information about Mr. Rothwell, not about Eiffel. It is not, however, a very pleasant statement, for impressions are easy to spread and hard to fight. This is like when a person is being criticized: if Paul says Peter has stolen Paul's car, Peter can defend himself; if Paul spreads the rumor that Peter is a shady (or shaky) character, what can Peter do? I have strong opinions, and have not been shy in publicizing what I think of C++, but I have endeavored to focus on concrete technical arguments addressing specific points. Reciprocality will be appreciated. Mr. Adcock's suggestion is gratefully acknowledged but Eiffel's type system needs no fixing. I have had some trouble understanding his message; first I do not know the word ``backasswards'', although my limited but improving knowledge of English leads me to gather that this word is not likely to carry an entirely favorable connotation. Second, I have not heard anyone else criticize the Eiffel rule for redefining the ``return type'' (which I understand as the type of a function's result). In Eiffel this has to be a descendant of the original type, not raising any problem that I know of. What has been criticized before (and I must assume this is what Mr. Adcock really had in mind) is the rule for routine arguments, which is the same as for results. This shocks many people who approach the problem from a purely theoretical perspective; the absence of a precise discussion of this topic in my book ``Object-Oriented Software Construction'' did not help here. (Obviously I should have been more careful.) Unfortunately for the theoreticians, the Eiffel rule is the one that makes sense in practice. To take a very simple example, take the generic class LIST [T] with a procedure insert (x: T) Assume a class and one of its heirs, for example STUDENT and its heir UNIVERSITY_STUDENT. With the declarations sl: LIST [STUDENT] usl: LIST [UNIVERSITY_STUDENT] the call ``sl.insert (s)'' should be valid for any s of type STUDENT, but the call ``usl.insert (s)'' should be valid only for s of type UNIVERSITY_STUDENT. The ``contrapositive'' rule advocated by some would require that the version of ``insert'' for class LIST [UNIVERSITY_STUDENT] take arguments whose types are *ancestors* of STUDENT! This does not make sense - nor does the rule suggested by the authors of the JOOP letter, according to whom it should not be possible to change the argument types. They cite this as being the C++ rule. My congratulations to anyone who can write useful software in these conditions. (This is impossible, of course, and is one of the reasons why undisciplined type casts are constantly needed in such a context. I think this makes a mockery of object-oriented ideas.) What the above simply means is that type checking in an object-oriented language is more difficult than what a two-minute peek at the problem might suggest. By the way, Eiffel's genericity (parameterized classes, such as LIST [T]) only makes the problem more visible; the same argument could be applied without any use of genericity. A few more comments: 1. It would be immensely pleasurable if critics of the Eiffel type rules would work under the assumption that Eiffel's designers, although they have made mistakes and will undoubtedly make more, are not *totally* incompetent. 2. In the same vein, our experience may have given us a perspective that not all outside commentators enjoy. We have written tens of thousands of lines of typed, reusable object-oriented software, including libraries that are used daily by hundreds of people. Once again this does not make us infallible, but I know of very, very few people in the world today who have that kind of experience, and the appreciation it gives for what works and what does not. 3. I have seen no one mention what I think is one of Eiffel's significant contributions: a type system which is fully uniform, and entirely based on the notion of class. Even integers and booleans are theoretically based on classes (through ``expanded types''), with no loss of efficiency at the implementation stage. 4. One thing that does need fixing is the amount of type checking done by our current compiler, which misses some cases. The reason this has not been done before is that these cases occur extremely rarely in practice (for example there has not been a single recorded case in our company), so that we have devoted our forces to more urgent tasks. However the situation will be corrected in the next major release. 5. I have known for a long time Luca Cardelli's elegant work (A Semantics of Multiple Inheritance, in Semantics of Data Types, edited by Gilles Kahn, David B. McQueen and Gordon Plotkin, Lecture Notes in Computer Science 173, Springer-Verlag, New York, 1984, pp. 51-67). This denotational model of some of the properties of inheritance suggests a contrapositive rule. Enamored as I may be of denotational semantics, however, I think that in science theories should be made to fit reality, not the other way around. Physicists are not supposed to change experimental results which do not agree with the model. This, of course, assumes somewhat arrogantly that Eiffel's rules are ``the reality''. Quite frankly, I would prefer the type rules to be as simple as Cardelli's work suggests but, as mentioned above, I don't see any other usable solution than Eiffel's. If someone can come up with a better suggestion, I will be the first to embrace it. In the meantime, we'll have to live with a useful practical solution even if it pains the theoreticians. Sorry. 6. Finally, our group does not just talk about Eiffel but also implements it. The type rules that we use makes type checking more difficult. Like everyone else we prefer easy jobs to hard jobs; one more reason to welcome any simpler solution - provided it also works. -- Bertrand Meyer bertrand@eiffel.com
munck@linus.UUCP (Robert Munck) (03/09/90)
I wonder if others have noticed that there's a single strong divisor
in this thread, separating it into two warring groups. It corresponds
roughly to the C/Ada division, also C/anti-C and anti-Ada/Ada.
Basically, it's the "world view" that programming is a solitary activity
or a communal one. That is, that programming is done by one person, with
little or no contact with others, or that it's done by a group of some
size, in constant close contact and also spread out in time and space.
That dicotomy obviously splits the university crowd from the military-
industrial crowd; universities have the problem that cooperative work
is called "cheating" in most other areas, so it's difficult for them to
take any other approach to s/w eng. The m-i complex people have the
problem that they cannot take the risk of entrusting a project to a
single or small number of people because of the possibilities that they
will be hit by a bus, poisoned at the local Chinese restaurant, or leave
the company.
I don't know how the differences can be reconciled.
-- Bob Munck, MITRE ==> Unisys (STARS)
--
-- Bob <Munck@MITRE.ORG>, linus!munck.UUCP
-- MS Z676, MITRE Corporation, McLean, VA 22120
-- 703/883-6688woody@eos.UUCP (Wayne Wood) (03/10/90)
In article <101567@linus.UUCP> munck@linus.UUCP (Robert Munck) writes: > >That dicotomy obviously splits the university crowd from the military- >industrial crowd; universities have the problem that cooperative work >is called "cheating" in most other areas, so it's difficult for them to >take any other approach to s/w eng. The m-i complex people have the >problem that they cannot take the risk of entrusting a project to a >single or small number of people because of the possibilities that they >will be hit by a bus, poisoned at the local Chinese restaurant, or leave >the company. > >I don't know how the differences can be reconciled. just get rid of the M-I complex :-) just another '60's throwback :-) /*** woody **************************************************************** *** ...tongue tied and twisted, just an earth bound misfit, I... *** *** -- David Gilmour, Pink Floyd *** ****** woody@eos.arc.nasa.gov *** my opinions, like my mind, are my own ******/
chris@mcc.UUCP (Chris Robertson) (03/12/90)
In article <1990Mar4.005122.14121@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >Yeah, I was a C novice once. I'm glad that all the code I wrote then >is dead and buried. Oh no it ain't, Henry -- I saved it all, and it's available to any who ask for just a modest fee... hey, I could post sections of it, and we could all discuss it! (I guess I could skip the latter step if you were to to mail me Mucho$ Buck$, in small bills, in a plain brown wrapper...) (It's always nice to feel one's years at University weren't wasted -- of course, I *was* supposed to be studying Zoology at utzoo, not creative entrepreneurship and advanced blackmail! ;-) -- "Down in the dumps? I TOLD you you'd | Chris Robertson need two sets..." | chris@mcc.pyrsyd.oz
henry@utzoo.uucp (Henry Spencer) (03/14/90)
In article <101@mcc.UUCP> chris@mcc.UUCP (Chris Robertson) writes: >>Yeah, I was a C novice once. I'm glad that all the code I wrote then >>is dead and buried. > >Oh no it ain't, Henry -- I saved it all, and it's available to any who >ask for just a modest fee... hey, I could post sections of it, and we >could all discuss it! Sorry, Chris, my *real* C-novice days were back before you knew me, and the code from then really is dead and buried. Thank heavens. :-) I'd been using C for about five years by the time I started working at utzoo. This is not to say there isn't some slightly embarrassing code from more recent times... -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
weiner@novavax.UUCP (Bob Weiner) (03/14/90)
not all outside commentators enjoy. We have written tens of thousands of lines of typed, reusable object-oriented software, including libraries that are used daily by hundreds of people. Once again this does not make us infallible, but I know of very, very few people in the world today who have that kind of experience, and the appreciation it gives for what works and what does not. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner
weiner@novavax.UUCP (Bob Weiner) (03/14/90)
[Please pardon and disregard my last message which was inadvertently posted prior to my writing it. This is the intended message.] In article <264@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: > We have written tens of thousands of > lines of typed, reusable object-oriented software, including libraries > that are used daily by hundreds of people. As a user and supporter of Dr. Meyer's work on Eiffel, I feel qualified to take exception with his statement above. I certainly am unaware of any code that ISE (Dr. Meyer's company) has not yet released publicly but I hesitate to label the present set of Eiffel class libraries from ISE as 'tens of thousands of lines of ... reusable ... software'. It is true that the code may be reused, as may any code, but the present state of the libraries does not put them in the class of what I believe any experienced developer would want in reusable classes. More precisely: There are no performance characteristics given with any of the classes. There is little in the way of documentation explaining the protocols used by each class and the single line public comments associated with most class features (routines and attributes) mask some often needed information about the code internals. That is, very often the external specifications of features in these classes are quite incomplete. There is hardly any internal feature documentation. The class indexing provided with V2.2 is extremely spotty. I should also say that most of these libraries do work as expected and ISE is very generous with their source code licensing. Additionally, AT&T provides no significant class library with their C++ compiler; hence I would definitely choose a broad working class library over none at all (such commercially supported libraries will come, but they are not here today). My main point is that I simply can't imagine developing a system that uses the Eiffel libraries without examining the source code. Development through conformance to external specifications is truly my hope for when we reach the dawn of 'reusable software components'. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner