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: John G. Volan Subject: Re: Side-effect arithmetic again [was: Ada ... in embedded systems] Date: 1996/03/27 Message-ID: <4jchbi$ep0@dayuc.dayton.saic.com> X-Deja-AN: 144609184 distribution: world references: <4i6efq$dd9@dfw.dfw.net> <4j982l$cnh@usenet.srv.cis.pitt.edu> content-type: text/plain; charset=ISO-8859-1 x-xxmessage-id: organization: Science Applications International Corp. (SAIC) mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-03-27T00:00:00+00:00 List-Id: 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": Ada Identifier Gratuitous Abbreviation -------------- ----------------------- Standard Std Integer Int Interfaces Int [sic] Natural Nat Positive Pos Pos [sic] Pos [sic] Value Val Val [sic] Val [sic] Image Img Boolean Bool Character Char String Str Constraint_Error CErr Program_Error PErr System Sys Address Addr Text_IO TIO File_Type Ftyp File F Item I Width W Base B Create Creat [truly, truly, gratuitous] End_Of_File EOF package pkg procedure proc function func generic gnrc range rng access ptr abstract abs abs [sic] abs [sic] is = begin { end } ... etc., etc., ad nauseum 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"? (BTW, 'SUCC 'SUCCs :-) ) >By the way, a C programmer would laugh at this whole conversation. Let 'em laugh. Let them use their cryptic terse language, and let them adopt the cryptic terse style their cowboy culture favors. It makes no never mind to me. 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. 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. It's amazing to me that the same people who whine about a few measly keystrokes in a piece of code do not seem to have such a problem spelling the same words out completely when they're writing something for a human being to read (especially if it happens to be their boss :-). What's wrong with my last sentence? Yeah, software's ment to be read by human beings, too. >The C programmer wants to say foo++ ... Ada programmer [Socratically]: "You want to do a "++"? Hmm, that's cryptic to me..." [Winks knowingly at the other Ada programmers.] "What exactly do you _mean_ by this, um, "++" thing? What are you actually trying to _do_?" C programmer doing Ada: "Um, well, see, I don't want to have to do a lot of cutting and pasting of these variable names here just so I can do "+". I'm just trying to increment them..." Ada programmer: "Ah, so you want to _increment_. So it must mean that you want" [pregnant pause] "an _Increment_ procedure, right?" C programmer [feeling a little stupid]: "Gee, now that you put it that way, I guess so." Ada programmer [jovially]: "Well, why didn't you say so in the first place? No problem, here's how you can get one..." [Then again, folks, Socrates was not well-liked... :-) ] >... 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. 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. 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. 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. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature ( Name => "John G. Volan", E_Mail => "John_Volan@dayton.saic.com", Favorite_Slogan => "Ada95: The *FIRST* International-Standard OOPL", Humorous_Disclaimer => "These opinions are undefined by SAIC, so" & "any use would be erroneous ... or is that a bounded error now?" ); ------------------------------------------------------------------------