From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,751584f55705ddb7 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Side-effect arithmetic again [was: Ada ... in embedded systems] Date: 1996/03/29 Message-ID: X-Deja-AN: 144868018 references: <4i6efq$dd9@dfw.dfw.net> <4j982l$cnh@usenet.srv.cis.pitt.edu> <4jchbi$ep0@dayuc.dayton.saic.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-03-29T00:00:00+00:00 List-Id: In article <4jchbi$ep0@dayuc.dayton.saic.com>, John G. Volan wrote: >In article Robert A Duff, bobduff@world.std.com >writes: >>Pardon my saying so, but that's complete nonsense. You can't understand >>Ada programs without understanding the semantics of Ada, whether or not >>your identifiers are verbose or terse. Furthermore, it is completely >>irrelevant whether random folks off street can understand your Ada code. >>What matters is whether a professional programmer, who knows the >>language, can understand the code well enough to modify it without >>breaking it. > >Then why did we ever bother with any of the identifiers on the left >below, when the more terse identifiers on the right would have done >"just as well" ... as long as you happened to be a member of that >select coterie known as "professional programmers": Because using zillions of strange abbreviations makes the code harder to understand, FOR PROFESSIONAL PROGRAMMERS. My point is just that this has nothing to do with making the code understandable by random folks off the street -- that's clearly impossible. You cannot understand any substantial Ada program if you don't know Ada -- and using nice un-abbreviated identifiers won't change that fact. > Ada Identifier Gratuitous Abbreviation > -------------- ----------------------- >..[various examples deleted] > Create Creat [truly, truly, gratuitous] Yeah, that's a particularly bad one! >Or is this whole discussion just a case of "_our_ cherished >abbreviations (Inc, Dec) are things of ineffable beauty, but _those_ >abbreviations are utter abominations"? Using Increment instead of "++" isn't going to make the program horribly verbose. My complaint is that people are suggesting a generic instantiation, which is a bunch of useless verbosity, to replace something that's very simple in C. >But for better or for worse, Ada is (for the most part) a less terse >language. More importantly, the culture behind Ada tends to favor >saying what you mean as plainly as possible, so that _intelligent_ >people (not necessarily language experts) have a better chance of >reading it straight. No, I disagree. I don't care if people who don't know Ada can't read Ada. Of course they can't. I want Ada to be readable so that people who *do* know it can read it. (And, of course, it's always a good idea if the language is simple enough, so that people who *don't* know it can *learn* it.) >.. Ada culture does not tend to promote the invention >of ad hoc "codes" that only the initiated can decipher. If that >philosophy means you have to type in a few more keystrokes, well, >keystrokes are cheap. Misunderstanding can be expensive. Agreed. >[Then again, folks, Socrates was not well-liked... :-) ] For good reason! ;-) >>... and we Ada folks start rambling on >>about generic instantatiations and other complicated gobbledegook. >>Sheesh. > >Hey, don't look at me. My generics were about as inanely >direct as I could make them. My point is that they're not (and cannot be) "inanely direct" *enough*. If you try to convince a C programmer to change "foo[i]++;" to "Increment(Foo(I));", that's fine. But to require a generic instantiation in addition would make the C programmer laugh, and rightly so. I think we'd be better off just admitting that there's no direct replacement for ++ in Ada, and tell the programmer, "Sorry, but you have to write "Foo(I) := Foo(I) + 1;". >... It's other folks that keep >advocating gooping them up with complex agglomerations of 'Pos and >'Val and what-not, just to get some marginal extra capabilities. Yeah, I was complaining about that, too. >But you don't like a generic as a workaround at all? Alright, suggest >something better, maybe even an Ada0X improvement, if you think it's >warranted. I did suggest a different workaround, using derived types. Also, an earlier version of Ada 9X had an even better solution (IMHO): you could declare a procedure Increment, which would work on any integer type, without cluttering up your program with generic instantiations. The generic solution just isn't worth it -- all I want to do is add 1 to a variable. >...Just don't tell me the answer is: "Either thou must accept >the received perfection of Ada95 as it is, or thou mayst as well become >a C programmer". Sheesh indeed. OK, I won't tell you that -- I don't believe it. - Bob