lucio@proxima.UUCP (Lucio de Re) (03/19/90)
In article <1771@awdprime.UUCP>, sanders@sanders.austin.ibm.com (Tony Sanders) writes: > In article <8218@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: > > So is a multi-alternative case, as provided by Ada: > How do you do this in ADA? > > ... silly code omitted ... > > See how I left out the breaks on purpose. > > In ADA you wouldn't be able to do this without duplicating either the > case-expression (they aren't always simple numbers) or the statements. > I don't think that's a serious drawback, unless you have a very limited amount of memory. I like the facility that as you point out does not exist in ADA, but I have got around the same lack in Pascal and Modula 2 without any great identity crisis. And I have forgotten the break on occasion, but I have learnt to spot the error quite quickly, even though it is becoming more and more scarce in my code (I generally enter all the case clauses, then separate them with break's when using VI; in BRIEF, I would modify the macros to do this for me). It really is silly to knock a language on the basis of certain constructs. Good programmers will use ADA or C successfully and bad programmers will screw up in ADA or in C. We are not all or always good programmers and we need to be alert to different possible failings in the two languages. Can Bill Wolfe vouch for ADA having no failings? And, as justification for my satisfaction with C not putting too many checks in my programming path, I have the following similitude: I normally ride a motorcycle at speeds in excess both of speed limits and of traffic speeds. I have to be very alert to survive, as automobile drivers seem utterly oblivious of my presence. If I travel more slowly, my attention span decreases and I become less alert. Also, not being insured, I find I am more conscious of my vulnerability than I was when I was insured. Similarly, in C I try very hard to avoid its pitfalls. I follow this thread because of the pitfalls that have been brought up (none that I wasn't aware of, yet) and I regret my lack of ADA knowledge, at least to some degree. In Modula 2 I too often let the compiler pick up my distractions, which means that semantic errors are more likely to have crept in. Is ADA similarly soporific; if so give me C, and programmers under my supervision will program in Modula 2 because I know the quality of the code I produce and I also know the type of clever (read illegible, often wrong or at the very least incapable of coping with special cases) code that less disciplined programmers can produce in C. But it is an issue of survival. Bad C programmers will eventually hang themselves, the same way that bad motorcycling would have killed or crippled me long ago (and has killed and crippled others) had I indulged in it. C requires self-discipline where Modula 2 and ADA force discipline on you. The result is that C programmers have more freedom, the price for which is one of greater alertness or the possibility that the compiler won't pick up what might be a simple mistake, while ADA and Modula 2 programmers have to be devious to do what they may have to do that the language inhibits. And further, ADA suffers from a very bad disease: committeetis. By the time a committee completes a definition, it cannot possibly have included the latest developments in language design. Worse, once the definition is finalised, implementation stretches further and the language is (in at least some facets) obsolete by the time the implementation is complete. To quote an example from the other side, the ANSI standard for C has been superceded, prior to publication by the availability of C++ compilers. Ironic? The standard has its place, but it would be sad to stifle further development in C++ by promulgating a standard that freezes it at this stage, for example. We are learning so much, it is impossible to encompass all GOOD language features in any one committee generated standard (thank goodness!). Take another point. The "0b" prefix Walter Bright added to provide binary number representation is an obvious extension to C. The ANSI committee did not consider it, nor did Stroustrup. Well, I like it and I use it, and I would like it incorporated into the ANSI standard. Certainly I would hate to lose it because some committee states that its implementation invalidates my compiler's compliance with the standard. ---------------------------------------------------------------------- I used to design nuclear reactors and you should see the code that engineers and scientists come up with. Yuuuck! Spaghetti everywhere. -------------------------------------------------- (Kenneth L Moore) - Lucio de Re ...uunet!ddsw1!olsa99!proxima!lucio -------------------------------------------------------- lucio@proxima Disclaimer: He must have been joking!
karl@haddock.ima.isc.com (Karl Heuer) (03/27/90)
This subthread is C-specific. I am redirecting followups to comp.lang.c. In article <567@proxima.UUCP> lucio@proxima.UUCP (Lucio de Re) writes: >Take another point. The "0b" prefix Walter Bright added to provide >binary number representation is an obvious extension to C. The ANSI >committee did not consider it... It *was* considered, but rejected. I suspect the response was "Insufficient utility; Does not address a major deficiency; No established current practice" or something like that. >Well, I like it and I use it, and I would like it incorporated into the ANSI >standard. No problem. Campaign to have it added to gcc; hint to your other vendors that you like the feature. If it's current practice when the next time around, it has a much better chance of making it into C-2000. >Certainly I would hate to lose it because some committee states that its >implementation invalidates my compiler's compliance with the standard. The feature doesn't break any existing code. At worst, it requires a warning diagnostic when the compiler is run in strictly pedantic ANSI mode. The fact that ANSI doesn't support it is not an excuse for not providing it. Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint