From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,eebbadd7557faf6f X-Google-Attributes: gid103376,public From: pitre@n5160d.nrl.navy.mil (Richard Pitre) Subject: Re: The return of Ada95 Date: 1996/03/17 Message-ID: <4ii0cn$ltu@ra.nrl.navy.mil> X-Deja-AN: 143062976 references: <4ihm97$80s@rational.rational.com> organization: Naval Research Laboratory newsgroups: comp.lang.ada Date: 1996-03-17T00:00:00+00:00 List-Id: 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