Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[John G. Volan <John_Volan@ccmail.dayton.saic.com>]

In article <DovoDs.3ML@world.std.com> 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?" );
------------------------------------------------------------------------