karl@haddock.ima.isc.com (Karl Heuer) (02/27/90)
I'm redirecting followups to comp.lang.misc. In article <5479@ur-cc.UUCP> Michael Sullivan writes: >[A lot of strawman arguments] I don't think anybody is seriously arguing the position that you seem to be attacking. I also don't know how closely my position matches that of the other participants in this debate, but I'll state mine as a series of claims for you to agree with or rebut as you like. It's meaningless to say "the `break' keyword is {good,bad}"; you have to have an alternative to compare against. I will use the notation `C with feature X' to mean `a hypothetical language which is a lot like C but which has feature X'; then we can make statements like `C with X would be a better tool than C'. I am not arguing that C should be changed in this regard (except by adding warning messages where appropriate). Thus, the existence of a large body of code written in C-as-it-is-today is not a factor in such comparisons. We need to distinguish between keywords and the operations they denote. It turns out to be useful to distinguish two operations, which I will call `break-switch' and `break-loop', both of which are denoted by the keyword `break' (depending on context). I will use the term `fall-through' to denote the operation of flowing from the end of one case into the beginning of the next one; this operation is denoted in C by the absence of a `break' keyword in reachable flow at the end of a case block. Claim 0. Much use of fall-through in C is simply attaching several cases to a single action. (In fact, this is the `positive side' you quoted from the Holy Scriptures.) Some other languages achieve this by allowing multiple values to be associated with a single case label, instead. Thus, C with multiple valued cases would not need fall-through nearly as often. Claim 1. A break-switch is rarely needed at any point other than at the end of a case block. At the end of a case block, break-switch is needed much more often than fall-through. Claim 2. As a general principle, if there is a default action it should be the most common of the alternatives. This tends to minimize certain kinds of user errors. Definitions. Let `CX' be the language C with multiple valued cases, with automatic break-switch at the end of each case block, and with the `break' keyword denoting only the break-loop operation. `CX with jumpcase' is CX with an explicit keyword to denote the fall-through operations (overriding the default behavior of an automatic break-switch). Claim 3. CX with jumpcase would be better than C. Claim 4. CX itself would be better than CX with jumpcase (and hence better than C); the extra keyword doesn't buy you enough to be worth adding, and it would destroy the commutativity of case blocks, which is a useful property of CX. Claim 5. Because C, not CX, is what we actually have, and because of what I said in Claim 1, a useful feature of C compilers and/or checkers (lint) is the ability to produce a warning if (a) a `break' keyword denoting a break-switch operation appears anywhere other than at the end of a case block, or (b) a (reachable) fall-through operation occurs at the end of a case block. Claim 6. In the case of lint, at least, such warnings should be enabled by default. There should be lintpragmas (e.g. /*SWITCH*/, /*FALLTHROUGH*/) that can selectively disable them. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint
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
ggw@wolves.uucp (Gregory G. Woodbury) (03/03/90)
In article <16039@haddock.ima.isc.com> karl@ (Karl Heuer) writes: >I'm redirecting followups to comp.lang.misc. > >Definitions. Let `CX' be the language C with multiple valued cases, with >automatic break-switch at the end of each case block, and with the `break' >keyword denoting only the break-loop operation. `CX with jumpcase' is CX >with an explicit keyword to denote the fall-through operations (overriding the >default behavior of an automatic break-switch). > >Claim 3. CX with jumpcase would be better than C. ASSUMING that the multiple valued case is done "right", this is only moderately untrue. If a person really wants to have this, it is a simple matter to put a front-end between your code and the C compiler to fix-up the syntax. >Claim 4. CX itself would be better than CX with jumpcase (and hence better >than C); the extra keyword doesn't buy you enough to be worth adding, and it >would destroy the commutativity of case blocks, which is a useful property of >CX. Now here there is a severe problem. This assumes (like most language arguments) that the programmer doesn't care about having to repeat (a potentially large) block of code in order to handle certain situations. Given that many programmers do care about the efficiency and size of the code generated, it can be argued that CX (without jumpcase) is significantly less usefull than C. In certain classes of processing, you want to do something only slightly different and then do the same thing as something else. One could certainly program this as code to handle the difference and a subroutine call to the common code, and a case to just call the common code, but this begs the question of the tradeoff between simplicity of in-line code versus the cost of a subroutine call which is part of the judgement left to the programmer. -- Gregory G. Woodbury Sysop/owner Wolves Den UNIX BBS, Durham NC UUCP: ...dukcds!wolves!ggw ...dukeac!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw@ac.duke.edu ggw%wolves@ac.duke.edu Phone: +1 919 493 1998 (Home) +1 919 684 6126 (Work) [The line eater is a boojum snark! ] <standard disclaimers apply>
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/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
marsh@linus.UUCP (Ralph Marshall) (03/05/90)
In article <16078@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >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. Folks, Edit the newsgroups line! This thread keeps appearing in comp.lang.lisp, and we all know that since Lisp doesn't contain any design flaws that could trap the unwary programmer, we don't need to see it here... Ralph Marshall marsh@linus.mitre.org
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. ]
karl@haddock.ima.isc.com (Karl Heuer) (03/06/90)
In article <1990Mar3.051019.13096@wolves.uucp> ggw@wolves.UUCP (Gregory G. Woodbury) writes: >In article <16039@haddock.ima.isc.com> karl@ (Karl Heuer) writes: >>Definitions. Let `CX' be the language C with multiple valued cases, with >>automatic break-switch at the end of each case block, and with the `break' >>keyword denoting only the break-loop operation. `CX with jumpcase' is CX >>with an explicit keyword to denote the fall-through operations (overriding >>the default behavior of an automatic break-switch). >> >>Claim 3. CX with jumpcase would be better than C. > >ASSUMING that the multiple valued case is done "right", this is only >moderately untrue. If a person really wants to have this, it is a simple >matter to put a front-end between your code and the C compiler to fix-up the >syntax. (a) Of course I'm assuming it's done right. (b) Your statement is not incompatible with mine; even if CXWJ could be implemented with a simple preprocessor, it would still be a better% tool than C. (c) Although one can certainly write such a front end, it's not what I'd call simple. It's easy enough to implement automatic break-switch and explicit fall-through, but fixing the overloaded keyword is nontrivial: it cannot be done in cpp or even m4, unless you also change the loop syntax. Note that while (...) { ... switch (...) { ... break; ... } } is a valid CX fragment which breaks from the *loop*. >>Claim 4. CX itself would be better than CX with jumpcase (and hence better >>than C); the extra keyword doesn't buy you enough to be worth adding, and it >>would destroy the commutativity of case blocks, which is a useful property of >>CX. > >Now here there is a severe problem. This assumes (like most language >arguments) that the programmer doesn't care about having to repeat (a >potentially large) block of code in order to handle certain situations. First, note that the extension (the addition of jumpcase to CX) solves only one minor instance of the problem: the situation where the tail of one case is the entirety of another. If you have *two* cases that would both like to flow into a third, you can only reduce one of them this way. (This alone suggests that fall-through is not the best way to solve the problem.) It's also common to have two cases with a common tail, but each needs to do some case-specific code first, so neither can fall directly into the other (unless you test the selector again, to skip over the head of the second case). Checking my own code now, I find that I seem to use fall-through even less often than goto. I wouldn't be particularly bothered if, in those rare instances when I need to have one case merge into the beginning of another, I had to do the same thing& that I already have to do in the other situations described above. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint ________ % Modulo the disclaimer in my original article, that we're ignoring the fact that C already exists and is popular. & This action may be repeated code, a subroutine call, or a goto, depending on the circumstances.
andrewt@watnow.waterloo.edu (Andrew Thomas) (03/07/90)
In article x karl@haddock.ima.isc.com (Karl Heuer) writes: > Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint I'm sorry to hear that. Perhaps you should clean your drier filter? :-) -- Andrew Thomas andrewt@watsnew.waterloo.edu Systems Design Eng. University of Waterloo "If a million people do a stupid thing, it's still a stupid thing." - Opus
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