Re: += in ada

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

Russ wrote:

> At some point one must ask *why* Ada is so unpopular, despite the fact
> that the DoD forced its use on a massive scale. Yes, the DoD mandate
> created some resentment, but if Ada is really so good, those who
> adopted it under duress should have eventually learned to appreciate
> it. Many did, I realize, but why are so many of them now rushing to
> throw off the yoke?

I think that Robert Dewar hit the nail on the head many years ago.  In 
one of his Computer Science classes he asked the students how many 
enjoyed debugging.  A large majority raised their hands.  That is the 
problem.

I detest debugging.  In fact detest is probably to mild a word.  So I 
love Ada.  When I was at Honeywell many years ago (1982), a couple of us 
taught a course in Ada programming, complete with access to our Ada/SIL 
compiler which was of course somewhere between Ada 80 and Ada 83 at the 
time (except for one addition we kept hoping that the ANSI standard 
effort would fix, a decent notation for Boolean array literals).

We used the tapes from the Ichbiah, et. al. course that one of us had 
taken as well as three instructors who were pretty much constantly 
available to the students.  All of the students had been programming OS 
software at Honeywell in various assembler languages for years, and the 
selection process for students was designed to get a representative 
sample of the current Honeywell Small Systems programming staff.

The biggest and most shocking conclusion from the course was that we 
could easily pick out about 30% of the current programming staff who 
would NEVER be able to successfully program in Ada.   The 30% number had 
pretty wide bounds at the time, but we (Honeywell) went further.  We 
wrote a short questionaire that was given to all potential students 
before the course, and later used that questionaire before addtional 
sections of the Ada course, a Pascal course that I taught, and a C course.

Since the students who did well in the Ada course went on to write 
several significant parts of the next OS release in Ada, some from the 
Pascal course to write a section in Pascal, and there were three C 
projects.  (One which ended up using the C preprocessor to write very 
Ada-like code.)  After all this validation, we could use the 
questionaire on applicants for jobs and a larger portion of the existing 
staff.

The final conclusion was that, if you used Ada about 30% of the current 
staff were hopeless.  With C, the number was closer to 5%, in Pascal 
somewhere in between.  Ada showed more than a 100% cost benefit over 
using C, and a 350% benfit over assembler, on initial project costs, 
with Pascal somewhere in the middle.  As for maintenance costs, 
maintaining C code cost around 50% less than maintaining assembler, and 
we had no cost data for fixing bugs in Ada code--even after MOD 400 
Release 3.0 had been in beta test for more than a year, and in general 
release for six months after that.

But there were some serious problems from a management point of view to 
using Ada.  First, the training costs were well justified, but 
retraining everyone would bankrupt the division, whether we used 
internal or external training.  So any switchover would need to be 
evolutionary.  And Ada converts were just that.  They might be willing 
to occasionally use a code insert, or C for some low-level driver, but 
they would quit rather than be put back to working full-time in 
assembler or C once thay had worked on an Ada project for long enough.

Finally, the real bad news from an Ada perspective was using the survey 
on job applicants.  Unlike the numbers for current staff, less than 30% 
tested high enough on Ada compatibility, but 90% were capable of working 
in C.  And one of the biggest descriminators was that debugging question 
of Dewar's.  If you checked "Strongly Agree" to "I enjoy debugging my 
own code," forget Ada.  Even worse was the vote on "I enjoy debugging 
code written by others."  Check "Somewhat Agree" and forget Ada.  Oh, 
and the salery requirements were such that potential Ada programmers 
expected to make about 50% more than potential C programmers.

So the "short-term" decision was to switch from assembler to C for most 
code, and Ada for the more difficult sections of the OS.  I left the 
company before I found out what the long-term decision was, but I 
suspect that Ada was used less and less, not more and more.

Oh, and I can't tell this story without adding one anecdote.  A student 
in the class, Joe, called me up one morning and said he had found a bug 
in the Ada compiler.  Since compiler bugs and teaching the class were 
both high-priority, I asked him to bring his problem up.  He brought a 
listing with over sixty lines of declarations and about half-a-dozen 
statements all in one procedure.  I spend about twenty minuted figuring 
out what he was doing, and scribbled one statement at the bottom of the 
page.

"You can do THAT in Ada?"
"Sure."
"Okay, I'll go try it."
"What about the compiler bug."
"Let me try this instead, I'm not sure my code is right."
"Okay."  I marked two of lines of declarations. "You'll still need these 
lines, but the rest can go."

Ten minutes later, he calls back.  "It still generates the same code."

"Bring up a listing with the assembler output."
"Got one already."

It only took me a minute or so to look at the generated code.  There 
were exactly three one-word instructions for the procedure, and the last 
one was a return statement.  Pretty slick I thought.

"Looks okay to me."
"But you can't do that in three instructions!"
"Did you try running it?"
"Of course not! It can't work."
"Why not."
"It needs four instructions."
"No it doesn't look.  This first instruction loads the value of the 
first parameter into R1, and post-increments the stack pointer.  The 
second instruction indirects through the stack-pointer that now points 
at the second parameter, and indexed by R1.  The third instruction 
pre-decrements the stack pointer and does the return. I'm going to have 
to complement Harlan on this particular peephole optimization."
"But that's cheating!"

I later found out that Joe had "invented" the way to write that 
expression in four instructions, and his real purpose in writing the 
example was to show how inefficient any compiled language was.  Needless 
to say, Joe never turned in a completed assignment, and I think he 
stopped attending the course halfway through.

-- 
                                         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