Re: += in ada

["Robert I. Eachus" <rieachus@comcast.net>]

Hyman Rosen wrote:

 > Let me see if I understand this correctly. The acceptance criteria
 > were looser for programmers of what you and I both agree is a more
 > error-prone language? Those 30% who were hopeless for Ada were also
 > hopeless for C. That's why there were maintenance problems with the C
 > code.

I'd love to do a wink and a nod, and agree with you.  But I can't.  The
key issue was abstraction.  Some programmers just couldn't get it.  They
could generated decent code in C or assembler, but when it came to Ada,
they, like Joe, couldn't accept the idea of abstraction and information
hiding.  There may have been some way to reach those programmers, but we
didn't find it.  Anyone who gets information hiding tends to love Ada.

It all comes back that debugging question.  With information hiding the
amount of information the programmer needs to understand his code is
limited.  That means that the code--in the context of information
hiding--is much easier to understand.  But you HAVE to do unit test!
Otherwise you are trying to debug at several levels at once, and your
head hurts.

Of course, if you do design and unit testing right, then any bugs you
uncover during unit test are so immediately obvious that there is no
need for a debugger.  I hit one of those bugs last week, an off by one
error in the bounds of a slice.  It was immediately obvious from the
output of the test program which function had failed, and that function
had one assignment statement in it, so I didn't really need the compiler
telling me which line raised Constraint_Error.

The programmers who failed to succeed on the "homework" assignments
almost universally had a problem showing up when they, after skipping 
unit test, tried to debug their programs with the debugger.  Decent 
debugger, but when you are looking at code that is generated from 
multiple levels of abstraction the debugger as such is no help.  You 
have to insert print statements at different abstraction levels to find 
the problem--or go back and write those unit tests.

We called it the "one little bug syndrome" and it was a killer.  And I 
still see it in programmers today.  When their program doesn't work, 
they are sure that there is only "one little bug" remaining and 
suggesting they go back and do it right just infuriates them.

The other failures, although there were officially no grades, were those 
who insisted on working around Constraint_Error or compiler error 
messages rather than try to fix what was wrong.  Again user headspace 
adjustment--they couldn't accept that the compiler was helping them by 
generating all those messages.  It made me very understanding of the 
companies whose Ada policies said "No use of Unchecked_Conversion," and 
change requests for Ada 9X that basically asked for some way to work 
around such "stupid" rules.  Such understanding, of course, did not 
extend to changing the language.  The fact that I knew that many of 
these requests came from employees of companies who had relatively 
liberal policies on exceptions to the project software development guide 
helped me to understand what was going on.  In fact at the Ada 9X 
Requirements meeting in Ft. Walton Beach, I was able to point out that 
several of these requests were worded correctly:  "I am not permitted to 
use Unchecked_Conversion, and..."  Cut it at the and, emphasize the "I" 
and you understood.


-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the
goal of Art. It remains to work these concepts into a practical,
down-to-earth context, and for this there is nothing more practical or
down-to-earth than what I have been talking about all along...the repair
of an old motorcycle."  -- from Zen and the Art of Motorcycle
Maintenance by Robert Pirsig