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

[bobduff@world.std.com (Robert A Duff)]

In article <4jchbi$ep0@dayuc.dayton.saic.com>,
John G. Volan  <John_Volan@ccmail.dayton.saic.com> wrote:
>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":

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