The return of Ada95

The return of Ada95

[Kenneth Mays]

Hi,

I wanted to answer questions concerning Ada and Boeing - besides a 
few other things:

1. The Seattle Times "Can Computers Fly" article, June 1995-July 1995 
was the one. Boeing programmers had complaints on Ada and how C++ 
rivaled Ada programming. From what I read on the article (I do have 
it saved on disk), it looked like an Ada83 complaint. Ada95 was
standarized in Feb. 95 but I don't think the compilers were up to 
snuff back then. AdaIC is still compiling
validated Ada95 compilers!

2. Ada95 is a decent programming language, but it is a general 
purpose language. Also, it was originally designed for embedded 
systems. The problem with this is that C/C++ is also a good language. 
Talking with many programmers, you can write VERY tight code with 
C/C++ and play with pointers and registers (bit level) very easy. I'm 
sure you can find a way to do it in Ada95, but its concept wasn't 
designed for it. COBOL is good for businesses, RPG (Report Program 
Generator) is good for reports, C/C++ for systems software and 
machine code/assembly replacement, BASIC for algorithm development, 
and Ada95 for long maintenance support where C/C++ general-purpose 
maintenance is not cost-efficient.

3. Look at IBM. IBM still supports C, COBOL, and RPG. Around 1980, I 
started earning these programming languages and they are still good 
languages. Ada95 hasn't been solidified as you can't run out there 
and find a wonderful Ada95 development system (even though I'm trying 
to get Visual Ada95 for testing). I can buy Visual C++ 4.0 or Borland 
C++ 4.5/5.0, but try to get a decent Ada95 compiler and there is some 
trouble to be found. Even QuickBasic 4.5/MicroSoft BASIC Pro 
V7.0/Visual Basic are pretty standardized in their areas. Can you 
find an article in most popular magazines that spout off a great 
Ada95 compiler?!? Any advertisements from MicroSoft on Ada95 
packages? Hmmm, there is a lot to be said about this.

4. The Air Force is getting rid of Ada??? Well, I would think twice 
about that. Any business major would know that if your company spent 
millions on a development package, you will spend the money to 
maintain it (why reinvent a perfect wheel?). Personally, I would say 
that all future development is done in C++. Ada95 will fill in where 
it is needed. MicroSoft Basic Professional / QuickBasic 4.5 is able 
to handle most easy tasks so I wouldn't knock BASIC. Visual BASIC is 
great for GUI work. The concept is what is easy to maintain, what 
will get the job done, how much speed does the application need, and 
how much is it going to cost!!?!?

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. I mean, we like MicroSoft Excel (spreadsheet) and 
MicroSoft Word (wordprocesser). Hell, even MicroSoft Access 
(database) is taking over DBASE!!

Let me know you thoughts on Ada95 development.

Write to:
maysk@wg53.eglin.af.mil

Thanks,
Ken
 

Re: The return of Ada95

[Robert Dewar]

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.

Well we see many bogus arguments potentially used for language selection,
and this one is rather typical.

What can me meant by an industry-standardized Ada 95 compiler, or for
that matter an industry-standardized C++ compiler.

Yes, there many be compilers that are in pretty standard use (for either
language), but these off-the-shelf products are not going to be what is
used in avionics. Microsoft for instance is not in the business of
providing corss-development tools with FAA certified runtime systems?

If by industry standard, you mean compilers that are NIST-certified, that
indeed is a useful criterion, and by that criterion, Ada 95 is far further
along than C++. One can safely predict that there will be a range of 
NIST-cerfified Ada 95 cross-development systems before the first
NIST-certified C++ compiler appears (given the state of the C++
standardization process, this will take a while!)

Of course what we have here from Kenneth is not "answers", but merely
speculation. Who knows what language(s) Boeing will choose in the future,
but it is unlikely that they will make the choice based on bogus
reasoning (or for that matter merely because of what the programmers
"want").

Re: The return of Ada95

[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
 

Re: The return of Ada95

[Bob Crispen]

KMays@msn.com (Kenneth Mays) wrote:

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

Since we're both writing from home, there'll be no mistake about our
seeming to represent our various organizations.  Boeing is no more a 
monolithic organization than the Air Force is.  Eglin doesn't have all

the same values as Wright Pat and Boeing Huntsville doesn't have the 
same values as Boeing Commercial Airplanes (or so it might seem -- I'm

not speaking for my organization!).

I will tell you one thing for free, though.  Thanks to you guys and 
similar Army folks, we had so much Ada code lying around that when it 
came time to write a "quick, dirty and cheap" (I quote the exact words

of a person in charge of this part of the software) hardware in the 
loop driver for something we're working on in the commercial space 
domain, it became instantly clear that the cheapest, easiest way to go

was to do it in Ada, even though we had to teach one of our people how

to write Ada and CGI.

In fact, I've even serendipitously found the CGI code referred to here

last week, and am tweaking it to support the Web interface to our HITL

simulator.

There's some C++ elsewhere on that program, largely because there was 
some C lying around and for *extremely* complicated and boring reasons

having to do with board support packages for the CPUs and 1553 boards 
involved and the change in pricing policies and our extreme reluctance

to pay yet another development license for a favorite product.

In short, Ada won where it did on this program and lost where it did 
on this program for the simplest of all reasons: practical trade 
studies conditioned by a lack of much money.

Bob Crispen
crispen@hiwaay.net
I *said* I wasn't speaking for my company.  Weren't you listening?

Re: The return of Ada95

[Mitchell E. James]

paul@srv.net (Paul Whittington) wrote:
> Thanks to DLLs the
>integration of a system designed this way is a no-brainer.  Build the
>main program in Delphi 2.0 and have it call the business rule stuff
>written in Ada implemented as a DLL which in turn calls DLLs written
>in Delphi 2.0 that provide the backend support.  

I am doing some GUI development in Delphi and think that it is a great
tool for building client/server GUIs.  But, I have been told:

>Tom Griest <griest-tom@CS.YALE.EDU>
>Right now there are some technical issues relating to generating DLL's
>with Ada.  There may be a contract to fund a DLL development kit for
>GNAT/Win32.  If you are interested in "chipping in", let me know.

Since I do have a back end that I would like to use Ada95 for, how are
you making a DLL.

-------------------------------------------------
Mitchell James
mjames@cyberhighway.net
http://cyberhighway.net/~mjames/   {check out Ada95 Measurement Types}

(Otto Neugebauer, the historian of ancient mathematics, told a story 
about the boy Einstein that he characterizes as a "legend,")
As he was a late talker, his parents were worried.  At last, at the
supper 
table one night, he broke his silence to say, "The soup is too hot."
Greatly 
relieved, his parents asked why he had never said a word before.
Albert 
replied, "Because up to now everything was in order."
-------------------------------------------------

Re: The return of Ada95

[Simon Johnston]

> paul@srv.net (Paul Whittington) wrote:
> > Thanks to DLLs the
> >integration of a system designed this way is a no-brainer.  Build the
> >main program in Delphi 2.0 and have it call the business rule stuff
> >written in Ada implemented as a DLL which in turn calls DLLs written
> >in Delphi 2.0 that provide the backend support.
>
> I am doing some GUI development in Delphi and think that it is a great
> tool for building client/server GUIs.  But, I have been told:
>
> >Tom Griest <griest-tom@CS.YALE.EDU>
> >Right now there are some technical issues relating to generating DLL's
> >with Ada.  There may be a contract to fund a DLL development kit for
> >GNAT/Win32.  If you are interested in "chipping in", let me know.

Can you (Tom) tell us what the technical issues are? having done some
experiments on producing DLL's from GNAT I would be interested in your
opinion (I stopped due to lack of time).

> Since I do have a back end that I would like to use Ada95 for, how are
> you making a DLL.
>
> -------------------------------------------------
> Mitchell James
> mjames@cyberhighway.net
> http://cyberhighway.net/~mjames/   {check out Ada95 Measurement Types}
>
> (Otto Neugebauer, the historian of ancient mathematics, told a story
> about the boy Einstein that he characterizes as a "legend,")
> As he was a late talker, his parents were worried.  At last, at the
> supper
> table one night, he broke his silence to say, "The soup is too hot."
> Greatly
> relieved, his parents asked why he had never said a word before.
> Albert
> replied, "Because up to now everything was in order."
> -------------------------------------------------
>
>

with StandardDisclaimer; use StandardDisclaimer;
package Sig is
--,-------------------------------------------------------------------------.
--|Simon K. Johnston - Development Engineer (C++/Ada95) |ICL Retail Systems |
--|-----------------------------------------------------|3/4 Willoughby Road|
--|Unix Mail: skj@acm.org                               |Bracknell          |
--|Telephone: +44 (0)1344 476320 Fax: +44 (0)1344 476302|Berkshire          |
--|Internal : 7261 6320   OP Mail: S.K.Johnston@BRA0801 |RG12 8TJ           |
--|WWW URL  : http://www.acm.org/~skj/                  |United Kingdom     |
--`-------------------------------------------------------------------------'
end Sig;

Re: The return of Ada95

[Norman H. Cohen]

In article <00001a73+00002b8c@msn.com>, KMays@msn.com (Kenneth Mays) writes: 

|> Talking with many programmers, you can write VERY tight code with
|> C/C++ and play with pointers and registers (bit level) very easy. I'm
|> sure you can find a way to do it in Ada95, but its concept wasn't
|> designed for it.

Efficient low-level programming and systems programming were very much a
design consideration for Ada 95.  Have you looked at modular types,
Section 13, or the Systems Programming Annex?

--
Norman H. Cohen    ncohen@watson.ibm.com