Re: The return of Ada95

[pitre@n5160d.nrl.navy.mil (Richard Pitre)]

In article <4ihm97$80s@rational.rational.com> rlk@rational.com (Bob Kitzberger)  
writes:
> Kenneth Mays (KMays@msn.com) wrote:
> : Hi,
> 
> : I wanted to answer questions concerning Ada and Boeing - besides a 
> : few other things:
> ...
> : Boeing is heading toward C++ future development in their avionic 
> : systems. : I'm sure they will support Ada95 if their programmers want 
> : to, but first lets find a industry-standarized Ada95 compiler that 
> : everybody can use. 
> 
> Kenneth, can you state your qualifications for making this statement?
> How can we determine that your "answers" are anything but pure 
> conjecture?
> 
> As to your comments about industry-standardized: rarely do large 
> safety-critical real-time projects give a hoot about using development 
> tools that are industry-standardized, if you mean in the Microsoft-Visual C++ 
> kind of way.    They have _very_ specialized needs that often 
> require an entirely different, set of strengths.  By their very
> nature, safety-critical systems have requirements that limit 
> the applicable tool sets to a tiny fraction of the development
> tool universe -- which basically excludes 'industry standardized
> compilers'.  Sophisticated code coverage analysis, rigorous
> documentation and testing requirements, predictability, reliability,
> determinism, adherence to standards, etc. are the driving factors 
> behind safety-critical systems development tool selection. 
> This is not the same set of requirements driving main-stream 
> development tool selection.
> 
> --
> Bob Kitzberger	      Rational Software Corporation       
rlk@rational.com

If Boeing is really headed for a C++ future then we will have an expensive  
experiment. They've done one with Ada. The only teeny little problem that I see  
is that the final tally will be in lives. Its fine for us to justify our tool  
preferences to our peers and its great to be confident in our abilities to  
write good code, but, there is a critical need for objectivity here. Don'tcha  
all agree.

Its never been a question of whether or not you could or could not do a  
particular thing with a language. You can do everything in anything. If you  
can't then its nothing. The question is how consistantly and correctly can  
human beings do what must be done with a tool. I guess its an ergonomic issue  
as much as anything. I'm just learning Ada but I would say, based on my limited  
experience with Modula 2 and Ada's similarities to Modula 2, that more  
programmers need to seriously experiment. What follows is  a description of my  
experiment with Modula 2, followed by brash but vague opinions about extending  
the charter of the Ada committee(or whatever it is).

I once owned an Amiga which I programmed in Basic. When that was too slow I  
bought a macro assembler to write dll's that Basic could call. The first time I  
had to implement a stack I ended up writing a bunch of macros and I figured  
that I was rediscovering C. Valuing my time, I ordered a C compiler and  
hurridly read a  C book while I anxiously waited for the compiler(Manx) to  
arrive. Now my Amiga did not have memory protection or a hard drive and I  
quickly discovered a dark secret about C. It liked to take my system out. It  
seemed somehow almost personal. By the time I had a written few little  
programs, I had developed elaborate reboot startup sequences from the ramdisk.  
I laboriously inspected my code before every test run. I looked at total system  
memory before and after each run and if it didn't match then I figured my  
system was on a timer, tic tic tic tic. I kept at least three copies of  
everything. I considered sprinkling chicken blood on my keyboard each time  
before hitting the enter key. At my lowest point, in a debugging marathon of my  
first real data structure in C, I woke up with my face on my desk in a puddle  
of drool next to my keyboard. Thats how I learned to think about the C stack  
and thats the first time I envisioned adding C wards to hospitals. It was a  
stressful existence and I learned to be careful, I thought. 

One day I decided to try Modula 2 for a bit. I had done a little Pascal on a  
C64 and M2 looked interesting but, in retrospect, I think that I did it because  
I have a language fetish. I was actually sweating by the time I got that damned  
compiler to pass my first programs. To me the source code looked uglier than  
the devils asshole. BUT. My code tended to run right out of the compiler. You  
could have knocked me over with a feather.  I didn't know much about syntax and  
semantics and computer science in general so it was indistinguishable from  
magic to me and I thought(still do) that N. Wirth was a magician. I wrote a dll  
in M2 (there weren't cushy tools for it back then) and it ran the first time. I  
litterally couldn't believe it and went to bed disappointed that the library  
wasn't working. I just knew that the bugs would be harder to find because the  
code was "pretending" to run. I was wrong. 

Eventually, I had to face the fact that my M2 compiler implementation was poor  
and incomplete and that I could not get good support for it. So I went back to  
C. What an exciting idea that was. Thinking back on my first C programs was  
like being an alzheimers patient on a good day watching a video of himself on a  
bad day(my canonical analogy). My next piece of code was going to be an octree  
for a color coding scheme tailored to the Amiga's hold and modify hardware  
color system. For efficiency I linked the octants in a ring and doubly linked  
the leaves in order to drain the tree once it was built. I walked around the  
problem and growled at it for a few days trying not to think about the joys of  
rebooting. In addition to doing raindances and chicken blood rituals, I put  
conditionally compiled bounds checking in every routine that seemed to matter.  
I didn't do everything that I thought the M2 compiler was doing but I did some.  
I don't think C was ANSI yet. It was a LOT of extra work. The program worked  
beautifully. So I was glad of my M2 experience because otherwise, considering  
my hardware and my programming abilities at the time, I don't believe that I  
could have written that code in C. I also believed then as I believe now that I  
will never even remotely systematically equal what that M2 compiler did for me.

Unfortunately there are some meta level "ergonomic" issues that were ignored in  
addressing the problems that I think Ada was intended to address.  A few that  
occur to me are:

No matter who you are you can't tell people what to do, at least not forever.
Learning new things is costly and painful and never happens automatically.
Programmers sometimes worship(tame word) their programming tools. 
Program managers are, well, program managers.
Without some mechanism to motivate  quality implementation a language 
    specification is pointless. (Funding GNAT seems to address this)

The Ada committee, needs to address these kinds of issues more directly. 


Finally, it seems to me that the COTS notion is a disease which eventually will  
defeat attempts to solve the problems that the specification of Ada was  
intended to address. People who are gloating about this seem to forget that the  
problems are effectively unaddressed if Ada bites the dust and that real people  
will really die because they these problems are not addressed. 
Issues that the COTS notion addresses might be better addressed by a language  
independent linking mechanism specification. Those of you who've read my posts  
are going to groan, "here he goes again about some vague linking nonsense".  
Sorry. Perhaps something like ILU. A language for defining interfaces. Things  
like RS232, SCSI, and other bus standards are nothing but fixed interface  
specifications and these specifications solve a tremendous number of problems  
even though they are not perfectly adhered to. I think language developers and  
implementers would be only too happy to have a language independent interface  
specification with muscle. This would give programmers and program managers  
more freedom to use optimal tools and it would solve one of Ada's bigger  
problems if such a standard caught on. I know that things are afoot to solve  
this interface problem but I think that the Ada  committee should convene for  
the purpose of addressing an  inteface language specification as a standalone  
issue. 

I'm saying that the Ada committee should extend their charter in order to  
achieve their real goals. I know that Ada has facilities to link to old  
languages but this is really not a substitute for a language independent  
interface specification language. So we need yet another language but this one  
one impose on programmers and the other people involved will have plenty of  
motivation to see to it that it happens once the specification is here.

richard