* Re: Ada ad in Embedded Systems Programming stinks
@ 1994-10-13 10:51 Bob Wells #402
1994-10-27 5:45 ` Ada in Australia (was Ada ad in Embedded Systems Programming stinks) Brendan WALKER
0 siblings, 1 reply; 34+ messages in thread
From: Bob Wells #402 @ 1994-10-13 10:51 UTC (permalink / raw)
Brendan WALKER <bjw@F111.IASSF.EASAMS.COM.AU> writes
> PS: We do NOT have an Ada mandate from our DoD in Australia, but on
> some defence projects in the past Ada has been specified. This practice
> is now almost extinct.
G'day Brendan,
Do you mean that the Collins submarine project, the ANZAC frigate project
and the JOHRN project aren't being done in Ada?
Bob W. (-:
^ permalink raw reply [flat|nested] 34+ messages in thread
* Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-13 10:51 Ada ad in Embedded Systems Programming stinks Bob Wells #402 @ 1994-10-27 5:45 ` Brendan WALKER 1994-10-28 16:17 ` William Fang 1994-10-30 1:14 ` Andrew Lees 0 siblings, 2 replies; 34+ messages in thread From: Brendan WALKER @ 1994-10-27 5:45 UTC (permalink / raw) In article <9410131051.AA29342@eurocontrol.de>, Bob Wells #402 <wel@EUROCONTROL.DE> wrote: >Brendan WALKER <bjw@F111.IASSF.EASAMS.COM.AU> writes > >> PS: We do NOT have an Ada mandate from our DoD in Australia, but on >> some defence projects in the past Ada has been specified. This practice >> is now almost extinct. > >G'day Brendan, >Do you mean that the Collins submarine project, the ANZAC frigate project >and the JOHRN project aren't being done in Ada? >Bob W. (-: G'day to you too, Bob, No, that is not what I meant. The three programs that you mention were all contracted between 3 and 7 years ago! Some of these are in fact the projects to which I was referring where Ada has been mandated in the past. Note that in these cases, Ada was in fact mandated by the project office concerned, specifically for the one project only. My original statement that "We do NOT have an Ada mandate from our DoD in Australia" is correct. Note also that about 9 out of 10 RFT's coming out of the Australian DoD in the past few years DO NOT mandate Ada. The typical statement is that "A high level language, such as Ada, C, or C++ should be used". There is also usually a big emphasis on the use of COTS, (Commercial Off The Shelf), software in any proposed solution. It is also worth noting that of three Ada projects you mentioned, I know for a fact that at least two of these are in SERIOUS trouble, facing serious architectual/design problems and the resulting cost and schedule slip (like 3+ years late!!). ---------------------------------------------------------------------- -- Brendan Walker | The opinions expressed above are obviously IASSF Project, | the ramblings of a troubled mind, and EASAMS (Australia) | therefore not those of my employer. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-27 5:45 ` Ada in Australia (was Ada ad in Embedded Systems Programming stinks) Brendan WALKER @ 1994-10-28 16:17 ` William Fang 1994-10-30 20:17 ` AdaWorks 1994-10-31 11:14 ` Andrew Lees 1994-10-30 1:14 ` Andrew Lees 1 sibling, 2 replies; 34+ messages in thread From: William Fang @ 1994-10-28 16:17 UTC (permalink / raw) Brendan WALKER (bjw@f111.iassf.easams.com.au) wrote: [...] : It is also worth noting that of three Ada projects you mentioned, I know for : a fact that at least two of these are in SERIOUS trouble, facing serious : architectual/design problems and the resulting cost and schedule slip (like 3+ : years late!!). My brother remember a local computer company that made PDP (is that?) clones getting the contract to supply computers for the Submarines. He did work experience there and remembers tha machines ranged from full-tower boxes to machines bigger than large filing cabinets, that he had to climb on top of to get access to some components. This was about 10 years ago. I'm not suprised that folks are having a hard time getting programs to work well on 10 year old computers. I'd be suprised if compiler vendors supported architectures that old. - Bill ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-28 16:17 ` William Fang @ 1994-10-30 20:17 ` AdaWorks 1994-10-31 11:14 ` Andrew Lees 1 sibling, 0 replies; 34+ messages in thread From: AdaWorks @ 1994-10-30 20:17 UTC (permalink / raw) In article <38r871$bdi@harbinger.cc.monash.edu.au> wfan1@lindblat.cc.monash.edu.au (William Fang) writes: >Brendan WALKER (bjw@f111.iassf.easams.com.au) wrote: > >[...] > >: It is also worth noting that of three Ada projects you mentioned, I know for >: a fact that at least two of these are in SERIOUS trouble, facing serious >: architectual/design problems and the resulting cost and schedule slip (like 3+ >: years late!!). > >My brother remember a local computer company that made PDP (is that?) >clones getting the contract to supply computers for the Submarines. >He did work experience there and remembers tha machines ranged from >full-tower boxes to machines bigger than large filing cabinets, that he >had to climb on top of to get access to some components. > >This was about 10 years ago. I'm not suprised that folks are having >a hard time getting programs to work well on 10 year old computers. >I'd be suprised if compiler vendors supported architectures that old. > >- Bill -- adaworks@netcom.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-28 16:17 ` William Fang 1994-10-30 20:17 ` AdaWorks @ 1994-10-31 11:14 ` Andrew Lees 1 sibling, 0 replies; 34+ messages in thread From: Andrew Lees @ 1994-10-31 11:14 UTC (permalink / raw) wfan1@lindblat.cc.monash.edu.au (William Fang) writes: >Brendan WALKER (bjw@f111.iassf.easams.com.au) wrote: >[...] >: It is also worth noting that of three Ada projects you mentioned, I know for >: a fact that at least two of these are in SERIOUS trouble, facing serious >: architectual/design problems and the resulting cost and schedule slip (like 3+ >: years late!!). >My brother remember a local computer company that made PDP (is that?) >clones getting the contract to supply computers for the Submarines. >He did work experience there and remembers tha machines ranged from >full-tower boxes to machines bigger than large filing cabinets, that he >had to climb on top of to get access to some components. >This was about 10 years ago. I'm not suprised that folks are having >a hard time getting programs to work well on 10 year old computers. >I'd be suprised if compiler vendors supported architectures that old. >- Bill Different submarines, different project, I believe. (Previous generation). Andy. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-27 5:45 ` Ada in Australia (was Ada ad in Embedded Systems Programming stinks) Brendan WALKER 1994-10-28 16:17 ` William Fang @ 1994-10-30 1:14 ` Andrew Lees 1994-10-30 2:41 ` Chris Perrott 1994-11-04 21:46 ` Do-While Jones 1 sibling, 2 replies; 34+ messages in thread From: Andrew Lees @ 1994-10-30 1:14 UTC (permalink / raw) bjw@f111.iassf.easams.com.au (Brendan WALKER) writes: [snip] >It is also worth noting that of three Ada projects you mentioned, I know for >a fact that at least two of these are in SERIOUS trouble, facing serious >architectual/design problems and the resulting cost and schedule slip (like 3+ >years late!!). Hmm, I suspect that I should not really respond to this, but the implication here (that Ada is involved in any problems these projects may have ) is simply too wrong to leave alone. I am aware of all of these projects, having been involved in one for seven years, having technically auditted one other, and having close contacts in the third. Where there have been problems, the root causes have been in the management domain rather than the technical. This is so on both of the projects that have had some difficulties. On the project that has not had difficulties, the same applies: the reason for its success has been consistently excellent management. In my direct experience (and despite my own doubts along the way) Ada has been a good implementation language for large projects. What needs to be understood is that no language can make up for unresolved management issues. When management issues start to become solved, projects start to make real progress. The design of the Ada language simplifies the management of the software production process considerably. When used well, the visibility structures of the language enable very rapid understanding to be obtained of code to which one has had no previous exposure. My role frequently involves system troubleshooting so I value this aspect of the language highly. I know of no other language in large scale use that would be as helpful. (Yes, I have spent many years developing software in 'C'). I see Ada as providing significant benefits in the development of large systems. Having said this, I can see that we are not yet taking proper advantage of all that can be gained from the language, with better design processes and attendent reduction in rework having particular scope for useful productivity improvements. >---------------------------------------------------------------------- >-- >Brendan Walker | The opinions expressed above are obviously >IASSF Project, | the ramblings of a troubled mind, and >EASAMS (Australia) | therefore not those of my employer. Andrew Lees. (andrewl@kralizec.zeta.org.au) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-30 1:14 ` Andrew Lees @ 1994-10-30 2:41 ` Chris Perrott 1994-11-01 9:45 ` Robb Nebbe 1994-11-02 15:35 ` Robert I. Eachus 1994-11-04 21:46 ` Do-While Jones 1 sibling, 2 replies; 34+ messages in thread From: Chris Perrott @ 1994-10-30 2:41 UTC (permalink / raw) In article <38us16$c0e@godzilla.zeta.org.au> andrewl@zeta.org.au (Andrew Lees) writes: >bjw@f111.iassf.easams.com.au (Brendan WALKER) writes: > >[snip] > >>It is also worth noting that of three Ada projects you mentioned, I know for >>a fact that at least two of these are in SERIOUS trouble, facing serious >>architectual/design problems and the resulting cost and schedule slip (like 3+ >>years late!!). > >Hmm, > >I suspect that I should not really respond to this, but the implication here Probably right! >(that Ada is involved in any problems these projects may have ) is simply >too wrong to leave alone. > >I am aware of all of these projects, having been involved in one for seven >years, having technically auditted one other, and having close contacts >in the third. > >Where there have been problems, the root causes have been in the management >domain rather than the technical. This is so on both of the projects that Well, yes and no. Ada 83 provides a way to get the address of a procedure, but doen't provide a way to _call_ a procedure using its address. Management decides that the project is to be done in pure Ada, and forbids use of assembly language to call a procedure using its address. >have had some difficulties. On the project that has not had difficulties, >the same applies: the reason for its success has been consistently >excellent management. > >In my direct experience (and despite my own doubts along the way) Ada has been >a good implementation language for large projects. What needs to be understood >is that no language can make up for unresolved management issues. When >management issues start to become solved, projects start to make real progress. > >The design of the Ada language simplifies the management of the software >production process considerably. > >When used well, the visibility >structures of the language enable very rapid understanding to be obtained Are the visibility structures of Ada 83 really any better than those of C++? Doesn't Ada 83 suffer from the lack of a structure larger than a package, something like the new C++ namespace? >of code to which one has had no previous exposure. My role frequently >involves system troubleshooting so I value this aspect of the language >highly. I know of no other language in large scale use that would be >as helpful. (Yes, I have spent many years developing software in 'C'). > >I see Ada as providing significant benefits in the development of large >systems. Having said this, I can see that we are not yet taking proper >advantage of all that can be gained from the language, with better >design processes and attendent reduction in rework having particular Better design methods would help, but watch out for management interpreting 'reduction in rework' to mean 'iterative development is forbidden'. >scope for useful productivity improvements. > >>Brendan Walker > >Andrew Lees. Chris Perrott ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-30 2:41 ` Chris Perrott @ 1994-11-01 9:45 ` Robb Nebbe 1994-11-02 15:35 ` Robert I. Eachus 1 sibling, 0 replies; 34+ messages in thread From: Robb Nebbe @ 1994-11-01 9:45 UTC (permalink / raw) In article <38v140$sdu@sunb.ocs.mq.edu.au>, cperrott@krakatoa.mqcs.mq.oz.au (Chris Perrott) writes: |> Are the visibility structures of Ada 83 really any better than those of C++? |> Doesn't Ada 83 suffer from the lack of a structure larger than a package, |> something like the new C++ namespace? Actually since Ada's packages aren't coupled with types it is a much more flexible encapsulation mechanism than classes in C++. In Ada 83 you could put anything you wanted in a package including other packages so it is certainly large enough. (Child packages are a better solution IMHO). Namespaces in C++ are being added to patch up a known defficiency in the language and make it easier to reuse software. Fortunately Ada 83 already had a very workable solution to namespace management. - Robb Nebbe ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-30 2:41 ` Chris Perrott 1994-11-01 9:45 ` Robb Nebbe @ 1994-11-02 15:35 ` Robert I. Eachus 1 sibling, 0 replies; 34+ messages in thread From: Robert I. Eachus @ 1994-11-02 15:35 UTC (permalink / raw) In article <38us16$c0e@godzilla.zeta.org.au> andrewl@zeta.org.au (Andrew Lees) writes: > Where there have been problems, the root causes have been in the > management domain rather than the technical. This is so on both > of the projects that have had some difficulties. On the project > that has not had difficulties, the same applies: the reason for > its success has been consistently excellent management. In article <38v140$sdu@sunb.ocs.mq.edu.au> cperrott@krakatoa.mqcs.mq.oz.au (Chris Perrott) writes: > Well, yes and no. Ada 83 provides a way to get the address of a > procedure, but doen't provide a way to _call_ a procedure using > its address. Management decides that the project is to be done in > pure Ada, and forbids use of assembly language to call a procedure > using its address. Is it just me or did everyone spot the irony here? Ada 83 does provide mechanisms for calling procedures given addresses, and for that matter for embedding assembler. It's just that the stnadard (correctly) points out that these things are dependent on characteristics of the implementation . Good management reads this as a reason to encapsulate the dependencies in a limited part of the code, clueless management forbids the use. The most ridiculous example of this was a revision request for Ada 9X where the functionality requested was already provided by Unchecked_Conversion. The request was of course turned down. But the requestor responded that Unchecked_Conversion was not a solution--his company coding standards did not allow him to use it! The only good news in all this is that we have found that it is harder for poor (or worse) management of an Ada development project to get the project in a state where the only viable option is to cancel it. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada in Australia (was Ada ad in Embedded Systems Programming stinks) 1994-10-30 1:14 ` Andrew Lees 1994-10-30 2:41 ` Chris Perrott @ 1994-11-04 21:46 ` Do-While Jones 1 sibling, 0 replies; 34+ messages in thread From: Do-While Jones @ 1994-11-04 21:46 UTC (permalink / raw) In article: 2009 of comp.lang.ada, Andrew Lees ( andrewl@zeta.org.au) writes: > bjw@f111.iassf.easams.com.au (Brendan WALKER) writes: > [snip] > >It is also worth noting that of three Ada projects you mentioned, I know for > >a fact that at least two of these are in SERIOUS trouble, facing serious > >architectual/design problems and the resulting cost and schedule slip (like 3+ > >years late!!). > Hmm, > I suspect that I should not really respond to this, but the implication here > (that Ada is involved in any problems these projects may have ) is simply > too wrong to leave alone. I can't leave it alone, either. Two years ago, I attended a design review for an Ada project that was in trouble. My observations were published in the June 1993 issue of Ada User (reproduced below with permission). Last month I checked up on the project. It has not failed (yet), but the software contractor came close to missing a payroll, and is flirting with bankruptcy. The project is way over budget and hopelessly behind schedule. They expect to deliver software that does not meet many of the requirements. As predicted, Innocent Ada Gets the Blame. +--------------------------------+ | Know Ada | | [Ada's Portrait] | | Will Travel | | | | wire do_while@ridgecrest.ca.us | +--------------------------------+ ------------------------------------------------------------ Reprinted from Ada User Ada Language UK, Ltd. with permission. ------------------------------------------------------------ 1 +---------+ | Opinion | +---------+ Innocent Ada Gets the Blame Do-While Jones I recently attended the software portion of a Critical Design Review (CDR) for an important project being developed jointly by two American armed services. One of the parties involved asked me to attend and give my assessment of the project status. It is my opinion that the project is in trouble, and Ada will get the blame, even though it isn't her fault. Unfortunately, this project is typical of so many software development projects. They are making the same mistakes that are so common these days, but these mistakes somehow remain unrecognized. Since Ada is supposed to save us from all our problems, she will get the blame when the project fails. We need to open our eyes to the real problems and concentrate on solving them, rather than blaming an innocent party. Four major problems surfaced at that CDR, but nobody seemed to notice. (1) The contractor and the U.S. government are working against each other, rather than working together. (2) The government-imposed software development methodology encourages the contractor to produce a bad design. (3) The contractor is trying to defeat Ada's software engineering features. (4) The contractor's configuration management system is badly flawed. The project in question is a real-time multi-media system that combines a graphical display of processed data with audio (voice) data. The audio data is digitized, compressed, and stored with the rest of the digital data so that the audio will remain synchronized with the graphical data when the event is replayed later for debriefing and analysis. The software is written in Ada for a Silicon Graphics workstation running X-windows on UNIX. Lack of Teamwork The attitudes of the people at the CDR quickly showed that the project is in trouble. This was apparent from an "us vs. them" relationship between the government and the contractor. The contractor was late and defensive. The government was angry and distrustful. There wasn't a team spirit. They weren't working together. Each side was eager to place the blame on the other. Here is an example: This project is an improvement of an existing system. One of the system requirements is the new system should have all the capability of the old system, and then some. The Silicon Graphics computers they are using have audio capabilities that the old system didn't 2 have. The old system could digitize and record audio data, but it had no way to play it back. It needed an external audio amplification system. Since it could not reproduce the audio data, it had a diagnostic feature that displayed audio data as hexadecimal values that scrolled off the screen faster than anyone could possibly read. Even if you could read them, there isn't a person alive who could tell what it sounded like. It was a totally useless feature. The contractor wasted time and money by designing a visual hexadecimal dump of audio data for the Silicon Graphics system. At the CDR, the contractor reported that they had done this, even though they knew the feature was stupid and worthless. Although they didn't come right out and say so, the tone of voice and body language said, "We knew that if we didn't implement this feature, the government would write us up as being deficient and penalize us for it, so we beat you to the punch by wasting your time and money and now there's nothing you can do about it because our lawyers say there is an iron-clad requirement for it. If you want us to take it out, it will cost you even more money. Ha, ha, ha!" The government has a long history of this kind of relationship with contractors. It is a direct result of the laws governing federal procurement. Corrupt people believe everyone else is as corrupt as they are. Lawmakers see trust and cooperation as unmistakable evidence of some under-the-table kickbacks or other unfair labor practice. Therefore, they have made it illegal to have any relationship with a contractor that is based on trust or cooperation. Contracts must always be awarded to the contractor who underbids the most. Actual cost of the contract is determined through litigation concurrent with project development. Methodology Maladies MIL-STD-2167A describes "the one true way for good software development." Unfortunately, that method is badly flawed, and problems experienced by a software project are generally proportional to the extent of its use. On this particular project, the government is strictly enforcing 2167A, with the usual disastrous results. Fundamental to 2167A is the "waterfall model" of development. This model requires that there be a Critical Design Review at the end of the design development phase. The project must obtain approval at this review before the implementation phase (i.e., writing code) may begin. The primary document reviewed at a CDR is the Software Detailed Design (SDD) document. In theory, this SDD contains all the pertinent design information needed to make an intelligent decision whether the project is on track or not. The approved SDD theoretically serves as the foundation for the coding effort. 3 Near the end of the presentation of the SDD at the CDR, a man sitting next to me whispered that he had just figured out what was wrong. Everyone was trying to guess what the user's manual would be like from the description of the software configuration items contained in the SDD. He thought that there would be much less argument and much more understanding if they simply wrote the user's manual first and presented it at the CDR instead. He was on the right track. Most people were trying to guess what the user's manual would be like, but the rest of the people were trying to guess what the Ada code would be like. Nobody really cared about the SDD. They were just trying to use the SDD as an awkward, indirect, unreliable way to find out what they really wanted to know. A preliminary user's manual and some carefully chosen code fragments from a prototype design would have told them what they really wanted to know. The questions that the government needed to ask the contractor were: How is it going to work? How are you doing it? How much have you done? When do you think it will be finished? What is the biggest problem facing you at the moment? What do you need us to do to help you? Do you still think it will cost what we estimated it would? Unfortunately, 2167A requires that contractors must cloak their methods, intentions, and progress behind a vague and ambiguous detailed design specification, and that they must present these specters and shadows using smoke and mirrors at a CDR. Everything I really needed to know, I learned in the hallway. In the hallway, the contractor was willing to admit that they already had written code and were testing it. In the hall, the contractor could tell the truth about what was really going on. Only on rare occasions during the formal presentations did the speakers slip and answer questions in a careless way that betrayed that the SDD hadn't quite kept up with their real design. The format of the SDD makes it difficult to clearly describe an existing design. Occasionally people in the audience asked about things that weren't shown in the detailed design document. The contractor's response was always that their design really satisfies the requirement, but the SDD just doesn't show it. For example, the X-windows services don't appear anywhere in the design specifications, yet it is X-windows that holds the whole program together. More than half of the code is X-windows and UNIX services, and they aren't mentioned at all in the SDD! One could argue that X-windows is an off-the-shelf product that isn't being designed by the contractor, so there is no need to document it. But X- windows controls the state transitions and largely determines the program structure. The Motif widget hierarchy is fundamental to the structure of the display screens. One can't describe the design without talking about these things. (Indeed, the reason I know how X- windows and Motif are being used is because the presenters 4 TALKED about them in the hall, but these critical details are entirely missing from the WRITTEN documentation.) Meanwhile, back at the CDR, one view graph gave estimates of memory usage and processing time. The estimates were inconsistent and ridiculous, so this naturally aroused some questions from the floor. After extensive questioning, the contractor admitted that some of these estimates came from "sound engineering judgment," and the rest of the "estimates" were really measurements of their prototype (which they didn't want to admit existed because they weren't supposed to be writing code yet). Several people in the audience wanted some indication of which numbers were measured and which were guesses. The contractor would not give that information. He argued that all that mattered was that the estimates said there would be at 30% spare time and memory. He even went so far as to say that if the measurements differed too much from the estimates, they would put more faith in the estimates than the measurements! The whole argument was really stupid. MIL-STD-2167A requires that the software developer estimate there will be 30% spare capacity, and they did. What's the big fuss about? Who cares if the estimate is bogus or not? There isn't any requirement that the estimate be correct. Of course it is necessary that the delivered system have enough spare time and memory that minor modifications can be made to the program and still run. If the program doesn't have enough spare memory, then the contractor is either going to have to add more memory, or do some space optimizations, whichever makes more sense. If the program doesn't run fast enough, the contractor will have to upgrade to a faster processor, or make some time optimizations. If nothing can be done to make the program small enough or fast enough, then some functionality will have to be removed. None of this is affected by the accuracy of the estimate of resource usage. Before any code is written or compiled, the estimate of program size and speed can't be much more than a wild guess. To allocate portions of this estimate to a preliminary guess of what software configuration items there will be in the final system is pure insanity. Yet, there is a requirement to produce such a space/time budget and present it at the CDR. Therefore, the contractor has to pull some numbers out of the air (or some darker place) and put them on paper. Furthermore, the numbers must add up to 30% less than the total, so it should be no surprise that they do. After wasting valuable time to produce this estimate, the contractor must present these numbers to the government as if they have some meaning or value. Any sharp government representative is going to see immediately how foolish they are, and challenge the contractor. The contractor is forced to defend his numbers. Thus the process forces the government and the contractor to be adversaries for no good reason! 5 Ada Ignorance In the hall, I asked the lead software engineer what he would do differently if he had to do the project all over from scratch. He immediately answered that he would do everything the same except he would use C instead of Ada. He blamed Ada for all their problems. Ada kept throwing up "roadblocks" to keep them from doing what they wanted to do. During a break I asked the program manager what she would do differently. She said there were two things she would do differently. First, she would do the documentation differently. She said that 2167A documentation required was badly formed and badly timed. The other change she would make is that she wouldn't use Ada. All the programmers complained about Ada, she said. At lunch I asked another software engineer some pointed questions about interfacing Ada with X-windows. He said that Ada will interface to X-windows, but you have to be careful to specify the proper link directives or the program won't run at all. He was rather negative toward Ada's strong typing, and said that they declared all their variables to be either integer or float whenever they had the opportunity. He thought it was unfortunate that the X- windows interface they bought from Verdix declares special integer types that required so many explicit type conversions. He also didn't like declaring subtypes with range constraints because he was afraid of CONSTRAINT_ERROR. He preferred to write his own range checking whenever he thought he needed it. Ada was specifically designed to promote good software engineering principles and discourage poor programming techniques. Ada makes it very easy to write good programs, and very hard to write bad ones. This contractor is struggling hard against Ada because the programmers are trying to do things Ada is designed to prevent them from doing. They are trying to write C-style code using Ada syntax. That's why it is so difficult. The SDD contained many configuration items for shared memory segments, semaphores, message queues, and pipes for inter-process communication. These are loud alarm signals. The proper way to do multi-tasking in Ada is to use Ada tasks. Properly written Ada programs don't need extensive use of shared memory, semaphores, queues, and pipes. They were using C calls to UNIX services to do their own home- brew inter-task communication! Mixing languages is tricky and not very portable. They were doing an awful lot of jumping back and forth between C and Ada, and every jump is a chance for error. They claim to be writing everything in Ada, but that can't be true. For example, there is a software configuration item design description that talks about forking another process and the signal that will be generated if the process fails (instead of an exception that 6 will be raised when a new task is elaborated). It must make a C call to a UNIX service, completely bypassing Ada. Another configuration item uses semaphores to control the execution of the other modules. A real Ada program would use parameterless entries into tasks for synchronization. Even without seeing the actual code, it is apparent that the contractor isn't designing an Ada program that makes a few calls to C graphics library routines. They are designing a C program that they are trying to write in Ada syntax. All the Ada safety features have been intentionally bypassed, and dirty tricks have been employed to try to keep the Ada tasking from ruining everything. Possible evidence that the contractor isn't proficient at Ada surfaced when there was a digression on how many times a person should be allowed to incorrectly enter a password. There was no requirement that said that the system should go into a catatonic state after the user enters the wrong password after a certain number of times, so the program lets the user try forever. When someone suggested that they add a limit of five tries, the program manager said that would not be an easy feature to add. All they have to do is put their existing do-forever loop inside a procedure and change it to a "for i in 1..5 loop" and return from inside the loop when the password is successfully entered. After five unsuccessful attempts, it drops out of the loop where the procedure could raise an exception. This should be a trivial change. Yet the contractor says it would be a major impact to the program, much too difficult and costly to add now. Why is that so difficult and costly? It might mean that their code was so badly written that it can't easily be changed. There is a good chance this is part of the reason, but there is another reason, too. To make this change they would have to add one more software configuration item. That is very difficult and costly for them. Their configuration management is killing them. Configuration Mismanagement The contractor briefly flashed many of the view graphs on the screen because there was so much design redundancy. Most of the display features in the live mode are identical to display features in the playback mode. So, they reused the design and made duplicate view graphs. They quite properly hand-waved many configuration items away saying, "This is just like something we've already talked about." Such a high percentage of design reuse would imply a high percentage of code reuse, but there isn't any real code reuse at all! Most of their configuration items were created by making a copy of the source code for another configuration item and using a text editor to change its name. They individually compiled, cataloged, and documented each of these source code modules that are identical except for their name. I asked why. The program manager and lead 7 software engineer both replied that their configuration management can't handle reusable library components. (Each software component needs to be associated with a particular configuration item. Two different configuration items can't share a software component.) It is obviously wasteful to maintain and document duplicate copies of source code. It is dangerous, too. There is a very good chance that a bug will be found and fixed in one of the components, but it won't be fixed in other copies of that component. It is also very wasteful of memory to have multiple copies of the same sequence of statements. They have to do this, though, because their configuration management system isn't compatible with Ada. Ada does a lot of the configuration management work for you. If you make changes to the specification of a compilation unit, she forces you to recompile everything that depended on the specification of that unit so she can make sure the interfaces still match. If you change something internal to the compilation unit that does not affect the specification, she does not force you to recompile anything else, but does automatically link the latest version of the object code each time you link a main program. So Ada makes sure that corrections are made in every use of common routines. Making differently named copies of common routines just defeats another of Ada's safety features. Even if their configuration management technique is so inept that it requires unique names for every different use of a common routine, there is a simple trick to keep configuration management happy. The software designers could do this: generic package BLAH_BLAH is -- Some commonly used routines are in this package. end BLAH_BLAH; with BLAH_BLAH; package LIVE_BLAH_BLAH is new BLAH_BLAH; -- This makes a copy of BLAH_BLAH called -- LIVE_BLAH_BLAH. with BLAH_BLAH; package PLAYBACK_BLAH_BLAH is new BLAH_BLAH; -- This makes a copy of BLAH_BLAH called -- PLAYBACK_BLAH_BLAH. Any change to BLAH_BLAH automatically makes LIVE_BLAH_BLAH and PLAYBACK_BLAH_BLAH obsolete. Any attempt to link them to a main program will fail with a link-time message saying that they are obsolete and must be recompiled. As soon as they are recompiled, they become current and can be linked. 8 (I don't really recommend this trick because configuration management should be able to keep track of reusable software components just as they keep track of electronic components that are used on multiple projects. I hope their hardware configuration management doesn't assign unique part numbers to every 10 K-ohm resistor on every different circuit board!) Ada environments typically have tools that software designers can use to answer the question, "If I make a change to BLAH_BLAH, what other compilation units will be affected?" The contractor is going out of his way to keep Ada from being able to answer that question by using different names for copies of the same thing. Some of the contractor's configuration management difficulties are symptoms of the Ada Ignorance already mentioned. They aren't used to packages, tasks, and library subprograms, so they just don't know how to keep track of them. People who use Ada correctly build up a library of reusable, tested, software components. This library full of building blocks is kept under configuration management. When new designs use existing library components they simply document them by reference to existing documentation. Clearly, this contractor doesn't have a configuration management system that allows them to do this. Some of their configuration management problems are symptoms of the Methodology Malady already mentioned. MIL- STD-2167A forces the designers to identify configuration items too early. It is not possible to guess in advance exactly which features will be identical and which will merely be similar. If you initially guess that two different configuration items can share a component, and later find out that they can't, configuration management makes it difficult to change your mind. Therefore, the apparently easy way out is to guess that all components will be unique. This creates problems later when you discover that some really are identical. Don't micro-manage software components before they have even been created. Unanticipated configuration items should freely appear later in the design, and useless configuration items should be allowed to disappear. Early configuration management often makes that too difficult. The result is that designers suffer with an awkward design just because it is too much trouble to get configuration management to let them do it right. The "5-try password entry" modification I mentioned earlier is an example. It would be a simple change to make, except for the fact that they would have to create a new software configuration item. The SDD would have to be modified to include this new configuration item. The requirements traceability matrix would have to be updated. The requirements document would have to be revised. Some drawings produced during the analysis phase would have to be 9 revised. All that work is just too much trouble. It is easier to let the design remain wrong. Conclusion The project will be very late and over budget, but it will eventually get done if the money holds out. It will meet the written requirements, but it won't meet the user's needs. In other words, it is a typical software development project. It has the same old problems projects always have because the MIL-STD-2167A software development process forces them to make the same mistakes. The only difference is that this time the government and the contractor will both put the blame on Ada for the added cost and delay, instead of trying to put the blame on each other. Both parties will save face, and Ada will be convicted because she has nobody to defend her. ^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <CvFI4J.D5M@world.std.com>]
[parent not found: <34ecqc$b5q@source.asset.com>]
[parent not found: <34g5v3INN6q2@phage.cshl.org>]
* Re: Ada ad in Embedded Systems Programming stinks [not found] ` <34g5v3INN6q2@phage.cshl.org> @ 1994-09-06 13:46 ` david.c.willett [not found] ` <EACHUS.94Sep6094018@spectre.mitre.org> 1 sibling, 0 replies; 34+ messages in thread From: david.c.willett @ 1994-09-06 13:46 UTC (permalink / raw) From article <34g5v3INN6q2@phage.cshl.org>, by pjm@isis.cshl.org (Pat Monardo): > In article <34ecqc$b5q@source.asset.com>, > Michael M. Bishop <bishopm@source.asset.com> wrote: >>some development work on some NASA applications in which I was forced to >>write in C. In C, of course, if you want to supply an OUT or IN OUT >>parameter as an actual, you have to pass its address. C compilers >>couldn't care less whether or not you actually pass an address. (I think >>ANSI C compilers give you a *warning* - big deal: it still accepts the >>code). If you forget to put the address operator on the parameter and, > > Now I understand why languages are religions. Listening to an Ada > person describe C is like listening to a Christian describe Hinduism. > Remember, C is a language, not an environment. If want to impose > discipline on your C code, then find a tool that supports your > religion. If you allow warnings to stay in your code, > then you are indeed in need of disciplining, try C++ :) > Pat, you win second place in the "short-sighted statement of the week" contest. The discipline you speak of is of no value to a program's writer. It is of value to those who must read the code. There are many more such folk then there are code writers. Furthermore, you neglect C's intrinsic low-level structure which makes warnings not all bad. Sometimes, even legitimate and safe C code will generate warnings. So it is quite hard to find a tool the "supports your religion" if your religion happens to be something like Ada's environment. <<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Dave Willett AT&T Advanced Technology Systems Greensboro, NC USA When short, simple questions have long, complex answers -- your organization's in trouble. Adapted from "In Search of Excellence" ^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <EACHUS.94Sep6094018@spectre.mitre.org>]
* Re: Ada ad in Embedded Systems Programming stinks [not found] ` <EACHUS.94Sep6094018@spectre.mitre.org> @ 1994-09-08 7:04 ` Dag Bruck 1994-09-08 9:52 ` Robert I. Eachus 1994-09-22 8:51 ` Brendan WALKER 0 siblings, 2 replies; 34+ messages in thread From: Dag Bruck @ 1994-09-08 7:04 UTC (permalink / raw) >>>>> "RE" == Robert I Eachus <eachus@spectre.mitre.org> writes: RE> Most Ada avocates, myself included, read, understand, and even use RE> C where appropriate. We do not treat C programmers as heretics, RE> we regard those who speak only C illiterate. I agree completely that experience with multiple languages is a great help in attacking programming problems, not the least because an idiom commonly used in another language may perfectly describe something that is unusual in the language you normally use. For example, in natural languages the Swedish word "lagom" describes something between two extremes that is satisfactory to all parties; I haven't yet found an English word with the same connotations (so pardon me for the imprecise description). I digress; I would instead point out that there are significant differences between C and C++, and several postings on comp.lang.ada do C++ unjustice by taking problems in C and transfering them to C++. First, there are several areas where checking in C++ is tighter than in C, for example: - function must be declared before it is called - function arguments must declared (not in K&R C) - no implicit conversion from void* to any other pointer - no implicit conversion from integer to enumeration - jumps may not by-pass variable initialization Second, C++ encourages a programming style that leads to better programs: - constructors/destructors provide guaranteed initialization and finalization - objects can be declared between statements, which gives a style where variables are not declared until they can be initialized (=> no uninitialized variables) - references, in particular as function parameters, reduces the use of pointers (references must be initialized and refer to an object) - classes give better program structure (cf. Ada packages) - better encapsulation of data (private parts of objects) It worth pointing out that the items above are "traditional" in the sense that they have nothing to do with object-oriented programming; C++ is more than "OO-C." There are of course newer features, such as, - support for OOP, inheritance and virtual functions - generics - overloading - exception handling RE> Passing an object instead of a pointer to it (the earlier RE> example) is a difference between Ada and C. As described above, this is a case where C++ should appeal more than C to the Ada programmer. Finally a comment on the Ada/C/C++ "language wars:" I think the issue is to use C++ instead of C, not to use C++ instead of Ada, at least for the great majority of programmers. -- Dag Bruck, C++ fan ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-08 7:04 ` Dag Bruck @ 1994-09-08 9:52 ` Robert I. Eachus 1994-09-08 17:12 ` Dag Bruck 1994-09-22 8:51 ` Brendan WALKER 1 sibling, 1 reply; 34+ messages in thread From: Robert I. Eachus @ 1994-09-08 9:52 UTC (permalink / raw) In article <DAG.94Sep8090447@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes: > I digress; I would instead point out that there are significant > differences between C and C++, and several postings on comp.lang.ada > do C++ unjustice by taking problems in C and transfering them to C++... > Finally a comment on the Ada/C/C++ "language wars:" I think the issue > is to use C++ instead of C, not to use C++ instead of Ada, at least > for the great majority of programmers. Hmmm... I will reply, but mildly. I have found several areas where C is a better implementation language than Ada. Since Ada is much better at programming in the large, this generally leads to large Ada applications with perhaps one or two percent of the unit bodies written in C. Of course when interfacing to large bodies of legacy C code, these numbers go up. However, when I have tried to use C++, the only advantages over Ada 83 lie in areas where other Ada 83 features make Ada the better choice. (Yes doing OOP in Ada 83 is painful, but I never found a way to use C++ OOP and encapsulate it. So the entire program structure must be in C++, and except on small projects, where the benefits of OOP are not that great, I'd much rather use Ada for program structure.) With Ada 9X now here, I get all of the advantages of C++ and none of the drawbacks--even if I don't use tagged types. (Generic package parameters and generic derived type parameters are enough to make static typed OOP work nicely. And I much prefer to use static typing when possible. Of course, in Ada 9X, I have a choice...) So even with C++ as a completely viable language choice, I never choose it. But I still sometimes use C. (And wash my hands afterwards. ;-) For that matter I still use APL and Lisp, and if I had a good Algol W compiler for a modern processor, I might use that to. (Why Algol W and not Pascal or Modula? There are times when real call by name and own variables are useful, but everything in Pascal and Modula can be found in Ada.) -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-08 9:52 ` Robert I. Eachus @ 1994-09-08 17:12 ` Dag Bruck 1994-09-08 17:28 ` Robert I. Eachus 0 siblings, 1 reply; 34+ messages in thread From: Dag Bruck @ 1994-09-08 17:12 UTC (permalink / raw) >>>>> "RE" == Robert I Eachus <eachus@spectre.mitre.org> writes: RE> I have found several areas RE> where C is a better implementation language than Ada. What areas, he asked curiously... I would be greatly interested in a discussion of things that C does better than Ada, in particular from someone whose understanding of Ada is beyond doubt. -- Dag Bruck ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-08 17:12 ` Dag Bruck @ 1994-09-08 17:28 ` Robert I. Eachus 0 siblings, 0 replies; 34+ messages in thread From: Robert I. Eachus @ 1994-09-08 17:28 UTC (permalink / raw) In article <DAG.94Sep8191257@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes: > What areas, he asked curiously... I would be greatly interested in a > discussion of things that C does better than Ada, in particular from > someone whose understanding of Ada is beyond doubt. The canonical example is device drivers. But any code where the bit representation is more important than the data's value or where you spend a lot of time "punning" between two different views of the same data fall in the same category. For example, a compression algorithm that uses variable length representations of repeated strings. You can write these in Ada--with liberal use of Unchecked_Conversion--but it is more readable if you use bit operations on integers, or union types, etc. Another (ancient) case was where I needed to find the first bit set in a large Boolean array. The trick was to convince the compiler to use the special string processing operations, then do a conversion from the first non-null character found to a bit offset. (Anyone else remember translate and test instructions? In any case, the array was very sparse, and this way the only use of memory bandwidth was to fetch data.) Could have written it in assembler, but this code was portable. It just wouldn't run anywhere near as fast on a different hardware architecture. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-08 7:04 ` Dag Bruck 1994-09-08 9:52 ` Robert I. Eachus @ 1994-09-22 8:51 ` Brendan WALKER 1 sibling, 0 replies; 34+ messages in thread From: Brendan WALKER @ 1994-09-22 8:51 UTC (permalink / raw) In article <DAG.94Sep8090447@bellman.control.lth.se>, Dag Bruck <dag@control.lth.se> wrote: >>>>>> "RE" == Robert I Eachus <eachus@spectre.mitre.org> writes: > >RE> Most Ada avocates, myself included, read, understand, and even use >RE> C where appropriate. We do not treat C programmers as heretics, >RE> we regard those who speak only C illiterate. > [stuff deleted] >I digress; I would instead point out that there are significant >differences between C and C++, and several postings on comp.lang.ada >do C++ unjustice by taking problems in C and transfering them to C++. > >First, there are several areas where checking in C++ is tighter than >in C, for example: > [deleted features of C++ in addition to C] >RE> Passing an object instead of a pointer to it (the earlier >RE> example) is a difference between Ada and C. > >As described above, this is a case where C++ should appeal more than C >to the Ada programmer. > >Finally a comment on the Ada/C/C++ "language wars:" I think the issue >is to use C++ instead of C, not to use C++ instead of Ada, at least >for the great majority of programmers. > > > -- Dag Bruck, C++ fan This is a good opportunity for some opinion from "down under". On the project I am currently working on we did see our choice as being between C++ or Ada. C was never considered. For general information, I will outline the main reasons why we chose C++ over Ada: - Use of GNU C++ Compiler coupled with Signus support contract was MUCH cheaper than purchase of multiple Ada compiler licences. We needed to distribute licences to many different machines, sites, and sub-contractors. - Price and availability of a wide range of proven development tools for C++ vs Ada. Especially in the area of GUI and other rapid prototyping tools. - Object Oriented Programming features of C++ over Ada-83, (9X was still twinkling in peoples eyes when we had to make our decision). - Ease of implementing low-level device driver and UNIX/VX-Works compatible Comms software with C syntax over Ada. Our project is a distributed 68040/VME and HP-Work Station based system that is being produced under contract to the Royal Australian Air Force. Note that most of the Engineers on the project have Ada backgrounds, with maybe a little C. We have found over-all that former Ada Software Engineers design and write excellent C++ software. Coming from an Ada background myself, I can add that I personally prefer C++ over Ada-83 in many ways, but particularily due to the extra dimension that the OOP features add to my ability to produce elegant designs and implementations. I suggest that the C++ critics actually give it a try.... In terms of tools and support (compiler bug fixes etc), down here the GNU C++/Signus compination is miles ahead of the Ada competition. The last Ada project I worked on here was stricken by a terribly slow and buggy compiler, a primitive tool-set, and an absolutely shocking level of support from the US-based compiler vendor, who shall remain nameless, suffice to say that they were one of the "biggies". The jury is still out until we finish our current project, but so far it looks as if C++ is here to stay in our organisation. PS: We do NOT have an Ada mandate from our DoD in Australia, but on some defence projects in the past Ada has been specified. This practice is now almost extinct. ----------------------------------------------------------------------------- -- Brendan Walker | The opinions expressed above are obviously IASSF Project, | the ramblings of a troubled mind, and EASAMS (Australia) | therefore not those of my employer. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks [not found] ` <34ecqc$b5q@source.asset.com> [not found] ` <34g5v3INN6q2@phage.cshl.org> @ 1994-09-07 22:44 ` John Goodsen 1994-09-08 6:32 ` Keith Thompson @pulsar 1 sibling, 1 reply; 34+ messages in thread From: John Goodsen @ 1994-09-07 22:44 UTC (permalink / raw) In article <34ecqc$b5q@source.asset.com> bishopm@source.asset.com (Michael M. Bishop) writes: From: bishopm@source.asset.com (Michael M. Bishop) Newsgroups: comp.lang.ada Date: 5 Sep 1994 02:11:24 -0400 Organization: Asset Source for Software Engineering Technology In article <CvFI4J.D5M@world.std.com>, Gregory Aharonian <srctran@world.std.com> wrote: [snip...] > "What's more, the compilers will stop, rather than allow incorrect code >to go through". Are you serious??? Do you think anyone will be impressed >by this claim? Has anyone at DISA ever looked at current C/C++ compilers, >which stop when they encounter errors and jump you back into the code, a >feature that has been around for years? As a marketing teaser, this statement >is useless. You might as well claim that Ada compilers allow you to compile, >link and run from the same pulldown menu. pragma Soapbox (On) Anybody with an ounce of software engineering sense should be impressed by the above claim! A couple of years ago (1990-91, actually), I did some development work on some NASA applications in which I was forced to write in C. In C, of course, if you want to supply an OUT or IN OUT parameter as an actual, you have to pass its address. C compilers couldn't care less whether or not you actually pass an address. (I think ANSI C compilers give you a *warning* - big deal: it still accepts the code). Wrong. A respectable ANSI C compiler will yell louder than a warning. And puke out on the compile when you don't pass a pointer when expected. -- -- John Goodsen Currently on-site at: The Dalmatian Group JP Morgan User Interface Specialists 60 Wall St., New York City jgoodsen@radsoft.com jgoodsen@jpmorgan.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-07 22:44 ` John Goodsen @ 1994-09-08 6:32 ` Keith Thompson @pulsar 0 siblings, 0 replies; 34+ messages in thread From: Keith Thompson @pulsar @ 1994-09-08 6:32 UTC (permalink / raw) In <JGOODSEN.94Sep7184437@trinidad.radsoft.com> jgoodsen@trinidad.radsoft.com (John Goodsen) writes: [...] > Wrong. A respectable ANSI C compiler will yell louder than a warning. > And puke out on the compile when you don't pass a pointer when expected. One data point: Sun's ANSI C compiler, in strict ANSI mode (cc -Xc) issues a warning: pulsar 1) cat -n foo.c 1 #include <stdio.h> 2 3 void func(int *p) 4 { 5 printf("p = %p\n", p); 6 } 7 8 int main(int argc, char **argv) 9 { 10 int i = 42; 11 func(i); 12 exit(0); 13 } pulsar 2) cc -Xc foo.c "foo.c", line 11: warning: improper pointer/integer combination: arg #1 I don't know what other ANSI C compilers do, but I presume Sun's is one of the most commonly used. -- Keith Thompson (The_Other_Keith) kst@alsys.com TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc. 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 /user/kst/.signature: I/O error (core dumped) ^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <1994Sep1.084046.21595@sei.cmu.edu>]
[parent not found: <344u9q$di5@gnat.cs.nyu.edu>]
[parent not found: <347idh$15ss@watnews1.watson.ibm.com>]
[parent not found: <1994Sep4.092729.21408@lmpsbbs.comm.mot.com>]
* Re: Ada ad in Embedded Systems Programming stinks [not found] ` <1994Sep4.092729.21408@lmpsbbs.comm.mot.com> @ 1994-09-07 22:46 ` John Goodsen 1994-09-08 6:47 ` Keith Thompson @pulsar 0 siblings, 1 reply; 34+ messages in thread From: John Goodsen @ 1994-09-07 22:46 UTC (permalink / raw) In article <1994Sep4.092729.21408@lmpsbbs.comm.mot.com> davidk@mcil.comm.mot.com (David Kramer) writes: To add to Norman Cohen's list of reasons why an Ada compiler is more effective than lint: It is much too easy to get around type mismatches in C - as any unscrupulous C programmer knows - all you have to do is use a cast! (eg. (Apples)oranges = apples). The lints that I have used had no problems with this - in fact in one project I worked on we were instructed to use lint and to have no warnings. The way our 'project leader' 'fixed' type mismatch problems was by casting it away! This isn't much easier than doing unchecked conversions in Ada. You identified a project management/process problem, not really a technological advantage of one language over another... -- -- John Goodsen Currently on-site at: The Dalmatian Group JP Morgan User Interface Specialists 60 Wall St., New York City jgoodsen@radsoft.com jgoodsen@jpmorgan.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-07 22:46 ` John Goodsen @ 1994-09-08 6:47 ` Keith Thompson @pulsar 1994-09-08 8:52 ` David Emery 0 siblings, 1 reply; 34+ messages in thread From: Keith Thompson @pulsar @ 1994-09-08 6:47 UTC (permalink / raw) In <JGOODSEN.94Sep7184648@trinidad.radsoft.com> jgoodsen@trinidad.radsoft.com (John Goodsen) writes: > In article <1994Sep4.092729.21408@lmpsbbs.comm.mot.com> davidk@mcil.comm.mot.com (David Kramer) writes: > To add to Norman Cohen's list of reasons why an Ada compiler is more > effective than lint: > > It is much too easy to get around type mismatches in C - as any > unscrupulous C programmer knows - all you have to do is use a cast! [...] > This isn't much easier than doing unchecked conversions in Ada. > You identified a project management/process problem, not really a > technological advantage of one language over another... Any Ada program that uses an unchecked conversion must have an explicit context clause for the generic function Unchecked_Conversion. This makes it very easy to tell that the program is doing something low-level and potentially dangerous. Furthermore, Ada clearly distinguishes between unchecked and checked conversions. C uses the same construct (the cast) for arithmetic conversions from int to float that it uses to coerce one pointer type to another. Ada doesn't prevent you from writing ugly, low-level, non-portable code, but it makes it more difficult to do it accidentally -- and that *is* a technological advantage. -- Keith Thompson (The_Other_Keith) kst@alsys.com TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc. 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 /user/kst/.signature: I/O error (core dumped) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-08 6:47 ` Keith Thompson @pulsar @ 1994-09-08 8:52 ` David Emery 0 siblings, 0 replies; 34+ messages in thread From: David Emery @ 1994-09-08 8:52 UTC (permalink / raw) It's my experience in porting software that the context clause ("with list") is one of the key parts of Ada portability. It establishes quite clearly what any given unit depends on. This observation is one of the major reasons that POSIX/Ada is defined as a set of packages, rather than one huge package. This way, if you see "with POSIX_Files, POSIX_IO;", you know there's a dependence on the file system, but NOT on processes and signal handling. dave -- --The preceeding opinions do not necessarily reflect the opinions of --The MITRE Corporation or its sponsors. -- "A good plan violently executed -NOW- is better than a perfect plan -- next week" George Patton -- "Any damn fool can write a plan. It's the execution that gets you -- all screwed up" James Hollingsworth ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks [not found] ` <347idh$15ss@watnews1.watson.ibm.com> [not found] ` <1994Sep4.092729.21408@lmpsbbs.comm.mot.com> @ 1994-09-11 3:41 ` Michael M. Bishop 1994-09-11 12:20 ` Robert Dewar 1994-09-12 20:49 ` Mitch Gart 1 sibling, 2 replies; 34+ messages in thread From: Michael M. Bishop @ 1994-09-11 3:41 UTC (permalink / raw) In article <347idh$15ss@watnews1.watson.ibm.com>, Norman H. Cohen <ncohen@watson.ibm.com> wrote: >And whenever I try to explain this to a dedicated C programmer, I receive >the reply, "What's wrong with just using Lint?" Ada promoters should be >prepared to answer this objection before they make the argument about Ada >facilitating the detection of errors. Here are some counterarguments, >some more compelling than others: [lots of good reasons that Ada compilers are better than C compilers + Lint snipped] My $0.02: The few times I tried to use Lint, either it didn't catch some actual problems with the code, or I had trouble figuring out the listing it generated. (Maybe I have a built-in bias against C or I'm just stupid. :-) Ada error messages include references to sections of the LRM so programmers can figure out why the compiler issued the error. -- | Mike Bishop | The opinions expressed here reflect | | bishopm@source.asset.com | those of this station, its management, | | Member: Team Ada | and the entire world. | ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 3:41 ` Michael M. Bishop @ 1994-09-11 12:20 ` Robert Dewar 1994-09-11 13:29 ` Robert Dewar 1994-09-11 21:48 ` Erik Naggum 1994-09-12 20:49 ` Mitch Gart 1 sibling, 2 replies; 34+ messages in thread From: Robert Dewar @ 1994-09-11 12:20 UTC (permalink / raw) Mike says: "Ada compilers include LRM references so the programmer can figure out the error" This of course is an attribute of an implementation not a language (C compilers and Lint could equally well include references to the ANSI standard). There are however real language differences that show up, e.g. when in C you casually write an unchecked conversion from pointer to integer, or you casually assume that pointers and integers occupy the same amount of space, or, or, or ... these are not errors in the sense of being static violations of some rule that Lint can easily catch. That being said, the fact that in Ada, the compiler is required to catch things means that it certainly will. A given implementation of Lint may or may not catch all the possible static errors (which were not designed into C in a manner guaranteeing that they could be detected). It's really that fundamental philosophical difference that is important. Standards like the COBOL, Fortran and C standards are basically only positive standards, they tell you what a legal program *is*, and what a conforming implementation must do with a legal program. The Ada standard is equally concerned with the class of illegal programs, and worries about what a conforming implementation must do with an illegal program. This isn't just theory, IBM has at least in one incident I know of, officially refused to accept as a valid bug report from an important COBOL user, a complaint that the compiler did not diagnose an error. Speaking of LRM references, especially with Ada 9X, where parts of the RM are very technical and do not even pretend to be simple easy to read English, I am not at all sure that routinely sending people off to look at the RM is a favor. In GNAT we really concentrate on giving an error message that is clear enough at a simple informal level to avoid the need to rummage in the LRM. Our eventual plans are to have an auxiliary utility which will further explain an error message, using additional text as well as references to the RM, AARM, Rationale or whatever. We haven't started work on that utility, but we have a good name for it GNOME (GNAT Online Message Explanation). That seems the best compromise. After all, remember that the user who is most likely to need further help is also the user least likely to be able to read the RM. If you really know the RM well, you shouldn't be making errors in the first place, and you certainly should be able to figure them out :-) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 12:20 ` Robert Dewar @ 1994-09-11 13:29 ` Robert Dewar 1994-09-12 14:03 ` Norman H. Cohen 1994-09-11 21:48 ` Erik Naggum 1 sibling, 1 reply; 34+ messages in thread From: Robert Dewar @ 1994-09-11 13:29 UTC (permalink / raw) ABOUT SUBJECT LINES You will notice that a long thread now, mostly discussing the issues of error detection in Ada and C, has had the above inflammatory subject, inherited from the original GA post. Now of course, many of us posting in this thread don't agree at all with the premise of the subject (I certainly don't), but I hesitate to change the subject since this will make it harder for some folks to follow the thread in thread reading news readers. It's an old trick in the newsgroup world to editorialize like this in subject lines, but it's really rather poor netiquette. It's better to post a neutral subject line (e.g. in this case leave of the stinks), and keep the flaming to the body of the text. That way we don't get misleading subject lines as the thread extends. Greg, we know from the author the tone of the message in advance anyway, so could you please try to use more neutral subjects. I think it will help the tone of discourse. Certainly it would be nice if others will follow this simple rule! ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 13:29 ` Robert Dewar @ 1994-09-12 14:03 ` Norman H. Cohen 0 siblings, 0 replies; 34+ messages in thread From: Norman H. Cohen @ 1994-09-12 14:03 UTC (permalink / raw) In article <34v0od$i0n@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes: |> It's an old trick in the newsgroup world to editorialize like this in |> subject lines, but it's really rather poor netiquette. It's better to |> post a neutral subject line (e.g. in this case leave of the stinks), and |> keep the flaming to the body of the text. That way we don't get misleading |> subject lines as the thread extends. It seems that my news reader, xrn, did the work for me! In its list of unread articles, it truncates the subject line to 42 characters, so until I saw Robert's post, I truly believed that all these postings had the subject line Re: Ada ad in Embedded Systems Programming (The body of the message contains the full subject line, of course, but I tend to ignore the header lines in a message body.) -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 12:20 ` Robert Dewar 1994-09-11 13:29 ` Robert Dewar @ 1994-09-11 21:48 ` Erik Naggum 1994-09-11 23:47 ` Robert Dewar 1994-09-12 19:16 ` Maarten Landzaat 1 sibling, 2 replies; 34+ messages in thread From: Erik Naggum @ 1994-09-11 21:48 UTC (permalink / raw) | That seems the best compromise. After all, remember that the user who is | most likely to need further help is also the user least likely to be able | to read the RM. If you really know the RM well, you shouldn't be making | errors in the first place, and you certainly should be able to figure | them out :-) kidding aside, I think this is a harmful view, because it assumes that those who are experts in a particular area of the language will also be experts in _all_ areas, and while possibly not _obviously_ wrong, this nevertheless has the unfortunate side effect of discouraging people from exploring new areas. this is what happens with C and C++, for instance, where once you get some particular way of doing something to work, you are not likely to look into ill-described alternatives. Ada should encourage programmers to become better programmers, not more "get it to work, dammit" programmers. programmers who _don't_ have readily available copies of the reference manual for the language(s) and libraries they use are a dangerous breed. #<Erik> -- Microsoft is not the answer. Microsoft is the question. NO is the answer. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 21:48 ` Erik Naggum @ 1994-09-11 23:47 ` Robert Dewar 1994-09-12 6:28 ` Dag Bruck 1994-09-12 20:03 ` Erik Naggum 1994-09-12 19:16 ` Maarten Landzaat 1 sibling, 2 replies; 34+ messages in thread From: Robert Dewar @ 1994-09-11 23:47 UTC (permalink / raw) But Erik, surely you can't think the RM is the right place to learn Ada style. Indeed much of the RM, of necessity, discusses marginal cases and rules that are there for semantic consistency, but are hardly valuable tools in the Ada programmer's arsenal. In the past, I have been a big supporter of the idea of all Ada programmers using the Ada RM as a major reference tool, but the Ada 9X RM, partly as a result of the increased complexity of the language, particularly in its type model, and partly because of the greater emphasis on a somewhat more formal style (in an attempt to be more precise), is considerably more difficult to understand than the Ada 83 RM. Erik, I would be interested if your opinions are arrived at with a thorough familiarity with the 9X RM, or are more just the way you hope things should be. Anyway, I continue to think that having optional RM references is what serves the community of people using GNAT best. 95% of the time, the RM reference would be completely unnecessary, even for a novice programmer, and only in a faction of the remaining 5% of cases would it really be a big help, and that's the case in which you can look it up. Note also that the GNOME approach gives much MORE than simply an RM reference, it gives a more thorough explanation, of which the RM reference is only one aspect. THe issue of how accessible defining documents should be is an interesting one. I am one of the relatively few people who got to know the Algol-68 revised report thoroughly. At that level of knowledge, it is a superb document, extremely precise, very complete, and very accessible. However, the great majority of people found it completely inpenetrable, and it clearly contributed to the demise of the language. I am afraid that if people's first introduction to using Ada at a simple level points to the RM, this will NOT be helpful in convincing people that Ada is simple to learn and easy to use. Of course experienced programmers will continue to use the RM as a primary reference source, and that's why it is valuable to get the error references when you need them. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 23:47 ` Robert Dewar @ 1994-09-12 6:28 ` Dag Bruck 1994-09-12 12:22 ` David Weller 1994-09-12 20:03 ` Erik Naggum 1 sibling, 1 reply; 34+ messages in thread From: Dag Bruck @ 1994-09-12 6:28 UTC (permalink / raw) >>>>> "R" == Robert Dewar <dewar@cs.nyu.edu> writes: R> THe issue of how accessible defining documents should be is an R> interesting one. I am one of the relatively few people who got to R> know the Algol-68 revised report thoroughly. At that level of R> knowledge, it is a superb document, extremely precise, very R> complete, and very accessible. R> However, the great majority of people found it completely R> inpenetrable, and it clearly contributed to the demise of the R> language. Have you seen the Draft International Standard for Modula-2? If nothing else will kill Modula-2, this document will! More seriously, the Modula-2 standard mixes natural language and VDM-SL (a formal specification language), and I think the mix is totally incomprehensible. The last statement is of course also a statement on my level of education. By the way, the reference manual has grown from some 30 pages to about 600 pages, and is bigger than the DIS for Ada 9X. -- Dag Bruck ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-12 6:28 ` Dag Bruck @ 1994-09-12 12:22 ` David Weller 0 siblings, 0 replies; 34+ messages in thread From: David Weller @ 1994-09-12 12:22 UTC (permalink / raw) In article <DAG.94Sep12082826@bellman.control.lth.se>, Dag Bruck <dag@control.lth.se> wrote: >[Robert Dewar writes] >R> However, the great majority of people found it completely >R> inpenetrable, and it clearly contributed to the demise of the >R> language. > >Have you seen the Draft International Standard for Modula-2? > >If nothing else will kill Modula-2, this document will! More >seriously, the Modula-2 standard mixes natural language and VDM-SL (a >formal specification language), and I think the mix is totally >incomprehensible. The last statement is of course also a statement on >my level of education. > >By the way, the reference manual has grown from some 30 pages to about >600 pages, and is bigger than the DIS for Ada 9X. > I recall the "bragging claim" for Modula-3 was that it not exceed 50 pages. Hmm, let's see, if we remove spaces, examples, libraries, implementation notes, cross-references, and reduce down to a 2-point font, we ought to be able to do that too :-) [Actually, a bit of trivia here (maybe not), the Ada 9X RM, sans Annexes,is actually smaller than the C++ Annotated Ref Manual (which I consider roughly equivalent) ] (for those of you looking to trash C++, this isn't a good metric -- both RM's take different approaches to describing features). the closest equivalent) -- Proud (and vocal) member of Team Ada! (and Team OS/2) ||This is not your Ada 9X -- It doesn't suck || father's Ada For all sorts of interesting Ada 9X tidbits, run the command:||________________ "finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 23:47 ` Robert Dewar 1994-09-12 6:28 ` Dag Bruck @ 1994-09-12 20:03 ` Erik Naggum 1 sibling, 0 replies; 34+ messages in thread From: Erik Naggum @ 1994-09-12 20:03 UTC (permalink / raw) [Robert Dewar] | Erik, I would be interested if your opinions are arrived at with a | thorough familiarity with the 9X RM, or are more just the way you hope | things should be. as we have discussed privately, my comments stemmed mostly from experience with Ada 83 RM. I have not come far enough into the RM9X to really see the differences you see as so enormous. so, a possibly premature apology for the possibly premature comments. however, I'm no foreigner to standards and their prose, which may of course also provide some bias in readability questions. (failed to understand Algol 68, though, but that was 10 years ago.) I don't usually confuse hopes with reality, but they _have_ tended to influence eachother. #<Erik> -- Microsoft is not the answer. Microsoft is the question. NO is the answer. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 21:48 ` Erik Naggum 1994-09-11 23:47 ` Robert Dewar @ 1994-09-12 19:16 ` Maarten Landzaat 1994-09-13 10:10 ` Richard A. O'Keefe 1 sibling, 1 reply; 34+ messages in thread From: Maarten Landzaat @ 1994-09-12 19:16 UTC (permalink / raw) Erik Naggum writes: >programmers who _don't_ have readily available copies of the reference >manual for the language(s) and libraries they use are a dangerous breed. > >#<Erik> >-- >Microsoft is not the answer. Microsoft is the question. NO is the answer. Your statement is not the answer. It is the question. NO is the answer. But seriously: I think you are exaggerating. Programmers should write 'good' code. One of the virtues of good code is that it uses constructs that anybody can understand. It's the same as with natural language: difficult sentences sound bombastic and don't get the message across. Although a manual within reach IS of course very useful... -- Maarten Landzaat (gijs@mbase97.xs4all.nl) Amsterdam, Double bass, Fender Jazz Bass, Atari ST, Roland Sound Canvas. Listen to M-BASE music! ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-12 19:16 ` Maarten Landzaat @ 1994-09-13 10:10 ` Richard A. O'Keefe 1994-09-17 12:07 ` Fred McCall 0 siblings, 1 reply; 34+ messages in thread From: Richard A. O'Keefe @ 1994-09-13 10:10 UTC (permalink / raw) gijs@mbase97.xs4all.nl (Maarten Landzaat) writes: >But seriously: I think you are exaggerating. Programmers should write >'good' code. One of the virtues of good code is that it uses constructs >that anybody can understand. It's the same as with natural language: >difficult sentences sound bombastic and don't get the message across. I think you have misunderstood the reason why it is essential to keep checking the manual. I personally am sick and tired of C code "that uses constructs that anybody can understand" but doesn't work. Example: someone else's code I'm _still_ trying to fix after a couple of weeks (ok, I'm not doing this full time) which, amongst other things, assumes that (a) pointers and 'int's are the same size and (b) casting a pointer to an int preserves all the bits. If I tell you that this is not true, you can probably guess which machine and what memory model... The point of checking the manual is not to become intimate with all kinds of super-whizzy features that demonstrate your wizard-hood, but to learn what kinds of things to _avoid_. Far too many people confuse what happens to work in their implementation, or what seems to them like the obvious translation, with what the language actually promises. The C standard, for example, is exceptionally valuable because it has appendices with long lists of things you _thought_ were ok but aren't. I was really shocked when I found out how many things I had relied on were just 'common extensions'. If you only have the programmer's reference manual for Brand X, you don't know what you _shouldn't_ be using. -- The party that took Australia into Vietnam wants to smash the inner-city yacht school and put a Grand Prix in its place. They don't change. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-13 10:10 ` Richard A. O'Keefe @ 1994-09-17 12:07 ` Fred McCall 0 siblings, 0 replies; 34+ messages in thread From: Fred McCall @ 1994-09-17 12:07 UTC (permalink / raw) In <353tqe$7pa@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au Richard A. O'Keefe writes: >I think you have misunderstood the reason why it is essential to keep >checking the manual. I personally am sick and tired of C code "that >uses constructs that anybody can understand" but doesn't work. Example: >someone else's code I'm _still_ trying to fix after a couple of weeks >(ok, I'm not doing this full time) which, amongst other things, assumes >that (a) pointers and 'int's are the same size and (b) casting a pointer >to an int preserves all the bits. Obviously written by someone who has been ignoring the advice of people who know C (the phrase "All the world is not a VAX" emanating from the direction of Toronto comes to mind). Note that someone who does this isn't going to be helped by a language manual. They're going to need to know a bit more about their environment -- which to my mind is information they ought to know, anyway. >The point of checking the manual is not to become intimate with all kinds >of super-whizzy features that demonstrate your wizard-hood, but to learn >what kinds of things to _avoid_. Or better yet, to learn what 'misfeatures' to look for in other peoples' code. Personally, I learned more C by reading comp.lang.c than I got from the books. Would that newsgroups were still as informative as they used to be. Howevver, I think it is a valid issue that Ada programmers typically NEED to look in the language reference more often. This is an expected result of the language being 'pickier' about what it will let you do. -- "Insisting on perfect safety is for people who don't have the balls to live in the real world." -- Mary Shafer, NASA Ames Dryden --------------------------------------------------------------------------- merlin@annwfn.com -- I don't speak for others and they don't speak for me. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Ada ad in Embedded Systems Programming stinks 1994-09-11 3:41 ` Michael M. Bishop 1994-09-11 12:20 ` Robert Dewar @ 1994-09-12 20:49 ` Mitch Gart 1 sibling, 0 replies; 34+ messages in thread From: Mitch Gart @ 1994-09-12 20:49 UTC (permalink / raw) Yes, lint catches some errors in C programs. But the Ada and C type models are fundamentally different. In Ada you might have: type Time is new Integer; type Temperature is new Integer; and then objects of these types are marked as being different, and cannot be assigned or mixed in arithmetic operations without a type conversion. The equivalent in C is: typedef int Time; typedef int Temperature; but now both of these types are treated like synonyms for "int". All the integer assignment and arithmetic operations are available, mixing objects of these types, without type coercions. Because of this fundamental difference in the type model, a whole class of errors won't be detected at compile time by any C compiler (ANSI or not) or lint. Mitch Gart ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~1994-11-04 21:46 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1994-10-13 10:51 Ada ad in Embedded Systems Programming stinks Bob Wells #402 1994-10-27 5:45 ` Ada in Australia (was Ada ad in Embedded Systems Programming stinks) Brendan WALKER 1994-10-28 16:17 ` William Fang 1994-10-30 20:17 ` AdaWorks 1994-10-31 11:14 ` Andrew Lees 1994-10-30 1:14 ` Andrew Lees 1994-10-30 2:41 ` Chris Perrott 1994-11-01 9:45 ` Robb Nebbe 1994-11-02 15:35 ` Robert I. Eachus 1994-11-04 21:46 ` Do-While Jones [not found] <CvFI4J.D5M@world.std.com> [not found] ` <34ecqc$b5q@source.asset.com> [not found] ` <34g5v3INN6q2@phage.cshl.org> 1994-09-06 13:46 ` Ada ad in Embedded Systems Programming stinks david.c.willett [not found] ` <EACHUS.94Sep6094018@spectre.mitre.org> 1994-09-08 7:04 ` Dag Bruck 1994-09-08 9:52 ` Robert I. Eachus 1994-09-08 17:12 ` Dag Bruck 1994-09-08 17:28 ` Robert I. Eachus 1994-09-22 8:51 ` Brendan WALKER 1994-09-07 22:44 ` John Goodsen 1994-09-08 6:32 ` Keith Thompson @pulsar [not found] ` <1994Sep1.084046.21595@sei.cmu.edu> [not found] ` <344u9q$di5@gnat.cs.nyu.edu> [not found] ` <347idh$15ss@watnews1.watson.ibm.com> [not found] ` <1994Sep4.092729.21408@lmpsbbs.comm.mot.com> 1994-09-07 22:46 ` John Goodsen 1994-09-08 6:47 ` Keith Thompson @pulsar 1994-09-08 8:52 ` David Emery 1994-09-11 3:41 ` Michael M. Bishop 1994-09-11 12:20 ` Robert Dewar 1994-09-11 13:29 ` Robert Dewar 1994-09-12 14:03 ` Norman H. Cohen 1994-09-11 21:48 ` Erik Naggum 1994-09-11 23:47 ` Robert Dewar 1994-09-12 6:28 ` Dag Bruck 1994-09-12 12:22 ` David Weller 1994-09-12 20:03 ` Erik Naggum 1994-09-12 19:16 ` Maarten Landzaat 1994-09-13 10:10 ` Richard A. O'Keefe 1994-09-17 12:07 ` Fred McCall 1994-09-12 20:49 ` Mitch Gart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox