Ada News Brief

Ada News Brief

[Reuse News]

Ada News Brief  
Week Ending:  October 4, 1996.  
  
****************************************  
  
OBJECTADA EDITIONS NOW AVAILABLE  
  
  
Thomson Software Products is now offering ObjectAda for   
Windows.  The new product is an object-oriented Ada 95   
development environment featuring Ada 95 compilers validated   
to run on HP 9000 Model J200 (under HP-UX 10.01) and on Sun   
SPARCstation 20 Model 712MP (under Solaris 2.5).  The   
compiler translates about 100,000 lines of code per minute   
on a 120-MHz Pentium-based PC, the company said.  ObjectAda   
for Windows includes the full Ada 95 core language and will   
compile all Ada 83 code without changes, according to the   
company.  The Professional Edition comes with a graphical   
user interface builder and a compiler that translates Ada   
sourse code into Java byte code.  The Enterprise Edition   
comes with MFC bindings, graphical libraries for plotting   
and drawing, DOS programming capabilities, support for   
Atria's Clear Case and a full support contract.  The   
Personal Edition comes with standard features.  The   
Professional, Enterprise and Personal editions were made   
available on September, 15, 1996.  
  
For more information on ObjectAda, please contact Thomson   
Software Products� Director of Marketing, Jacques Brygier,   
by phone 619/457-2700x135 or by e-mail   
jbrygier@thomsoft.com.  
  
SOURCE:  "Ada�s Back," by Justin Hibbard.  ComputerWorld,   
Internet Edition:  http://www.computerworld.com/search/AT-  
html/briefs/9608/960807ada.html.  
  
*****************************************  
  
TRI-ADA�96 ADVANCED PROGRAMS RELEASED  
  
The Tri-Ada�96 Conference Advance Programs are hot off the   
presses.  Tri-Ada �96, being held in Philadelphia, December   
3-7, 1996, will be featuring Barry Boehm, University of   
Southern California, Dennis Turner, U.S. Army, and Watts   
Humphrey, SEI, as the Keynote Speakers.  Savings of $100.00   
or more are currently available for early registrations.    
The Conference also coincides with the Army-Navy football   
contest being held at Veterans Stadium on Saturday, December   
7, 1996.  For more information on Tri-Ada�96, contact ACM   
Tri-Ada, PO Box 52300, Durham, NC  27717-2300.  Phone:    
800/338-5365 (USA and Canada only) or 919/419-8242.  Fax:    
919/490-0663.  E-mail:  74117.35@compuserve.com.  URL:    
http://www.acm.org/sigada/tri-ada/.  
  
SOURCE:  Tri-Ada�96 Conference Advance Program.  
  
******************************************  
 
The AdaIC's "Ada News Brief" is a compilation of summaries  
from Ada-related articles in trade magazines, newsletters
and press releases. The AdaIC welcomes suggestions for
and pointers to  Ada-related articles. 
Contact the AdaIC at: 
 
Ada Information Clearinghouse 
P.O. Box 1866 
Falls-Church, VA 22041 
1-800/232-4211 or 703/681-2466 
adainfo@sw-eng.falls-church.va.us 
http://sw-eng.falls-church.va.us 
 
To subscribe to the "Ada News Brief" electronic mailing  
list, send a 
message to: 
        listproc@sw-eng.falls-church.va.us 
In the body of the message, write: 
        subscribe adanews <your name> 
To unsubscribe, write: 
        unsubscribe adanews 
No signatures please. 

Re: Ada News Brief

[Ed Falis]

Reuse News wrote:
> 
> Ada News Brief
> Week Ending:  October 4, 1996.
> 
> ****************************************
> 
> OBJECTADA EDITIONS NOW AVAILABLE
> 
> 
> Thomson Software Products is now offering ObjectAda for
> Windows.  The new product is an object-oriented Ada 95
> development environment featuring Ada 95 compilers validated
> to run on HP 9000 Model J200 (under HP-UX 10.01) and on Sun
> SPARCstation 20 Model 712MP (under Solaris 2.5). 

This was a confused news release.  ObjectAda for Windows is hosted on Windows NT or
Windows 95, and can generate applications for these, Windows 3.1x or (with an
optional package) for DOS.

The platforms mentioned above are for ObjectAda 7.0 for UNIX, whose release is imminent
(if it hasn't happened in the last week).


The remainder of the news release was accurate enough, for the ObjectAda for Windows 
product.

Speaking for myself, not Thomson.

 > SOURCE:  "Ada�s Back," by Justin Hibbard.  ComputerWorld,
> Internet Edition:  http://www.computerworld.com/search/AT-
> html/briefs/9608/960807ada.html.
> 

-- 
Ed Falis
Thomson Software Products
(617) 221-7341

Re: Ada News Brief

[Keith Thompson]

In <533utt$43p@ns1.sw-eng.falls-church.va.us> reuseic@sw-eng.falls-church.va.us (Reuse News) writes:
[...]
>                                                   ObjectAda   
> for Windows includes the full Ada 95 core language and will   
> compile all Ada 83 code without changes, according to the   
> company.
[...]

I'm not sure where this statement came from, but it's not quite correct.
Ada 95 is very nearly upward compatible with Ada 83, so *most* correct
and portable Ada 83 code is valid Ada 95 code with the same semantics.
In one study I've read about, an program consisting of several tens of
thousands of lines of Ada 83 code, which had not been written with Ada 95
in mind, required no changes whatsoever.  Porting a program from Ada 83
to Ada 95 is typically no more difficult than porting from one compiler
to another.

The ObjectAda compiler does provide a command-line option to aid in
finding incompatibilities.  It's called "-83" in the Unix version (I
don't do Windows).  It does not turn ObjectAda into an Ada 83 compiler;
instead, it prints specific error messages for incompatible constructs
such as attempting to use "aliased" as an identifier.

The statement on our Web site (see
<http://www.thomsoft.com/products/ada/oa/oa2.html>) is:

    In addition, virtually all Ada 83 code will compile unchanged with
    ObjectAda.

As always, I speak only for myself.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Ada News Brief

[Robert Dewar]

Keith said

"I'm not sure where this statement came from, but it's not quite correct.
Ada 95 is very nearly upward compatible with Ada 83, so *most* correct
and portable Ada 83 code is valid Ada 95 code with the same semantics.
In one study I've read about, an program consisting of several tens of
thousands of lines of Ada 83 code, which had not been written with Ada 95
in mind, required no changes whatsoever.  Porting a program from Ada 83
to Ada 95 is typically no more difficult than porting from one compiler
to another.
"


There are other potential difficulties in porting from Ada 83 to Ada 95
in practice besides the known incompatibilities:

1. Bugs in the original compiler that it did not catch. We have run into
   instances of this with every Ada 83 compiler we have dealt with so far.

2. Bugs in the new Ada 95 compiler. As OCS systems pointed out, for at 
   least some time to come, every Ada 95 compiler will have some bugs.
   Indeed, given that we have had a fair amount of experience in running
   old Ada 83 compilers that are supposedly mature and finding bugs, maybe
   some time to come will be a while. Basically for any modern powerful
   programming language, it is likely that compilers have SOME errors.
   What one hopes is that this source of problems is small compared to
   other problems, and that is what we have found to be the case with
   GNAT so far, and I have heard similar anecdotal evidence for other
   Ada 95 compilers.

3. Rep clauses not implemented the same way. For example, last I knew,
   Ada Magic uses sparse array structures where the index type is an
   enumeration type with holes. GNAT used to do so as well, but we found
   that this generated critical incompatibilities with old Verdix code,
   and changed GNAT accordingly. There are *many* other cases of this
   kind of problem. Over time, this has been one of the most difficult
   areas to deal with, though by now, GNAT implements almost all the
   rep clauses we have run into.

4. Code that depends on implementation dependent details. For example, one
   of our large customers had a heck of a time tracking down a "bug" which
   turned out to be a case where a packed array of length (1 .. 32) of
   booleans was mapped to an external hardware address. The Verdix compiler,
   perfectly reasonably, loaded the entire 32-bit word to test one bit. GNAT
   perfectly reasonably, loaded only the byte containing the bit to be tested.
   Normally these two approaches would be identical, but their hardware could
   not handle byte addressing for this address. We "fixed" GNAT to do a word
   access in this case, but it was not of course a bug in GNAT.

5. Use of library packages, if code uses some vendor supplied package (e.g.
   Starlet on DEC), then of course porting it may be tricky.

6. Use of preprocessors that are either not available, or supported 
   differently in the new Ada 95 environment. We have prepared a
   preprocessor that is available with the current version of GNAT that
   can be used to handle some of these cases.

7. Use of pragmas and attributes not supported in the new compiler. For
   example, when porting DEC code, there are some programs which use the
   DEC pragmas and attributes (e.g. Import_Valued_Procedure pragma or
   the Null_Parameter attribute) that can be hard to translate. That is
   why we have implemented all these pragmas and attributes in GNAT.

That's not an exhuastive list, but the point is that the incompatibilities
between Ada 83 and Ada 95 have NOT proved to be a major issue in porting
existing Ada 83 code. It should also be said that our experience with GNAT
is that we have been able to port a number of large programs (in the several
hundred thousands of lines range) from Ada 83 to GNAT successfully, with a
very reasonable amount of effort and as we go, this gets easier. Interestingly
the reason it gets easier is not because of GNAT becoming generally more
solid (issue 2 above), but rather because we keep implementing new
functionality that alleviates other problems from the above list. In practice
at this stage, we find that compiler bugs are a relatively small part of
the porting issue.

And yes, Keith is still right that the effort to port from Ada 83 to Ada 95
is comparable to porting from one Ada 83 to another Ada 83. This is the
"distance" test that was established as a design requirement for the Ada 95
effort, and in practie, this criterion seems to have been met, which means
that operationally Ada 95 is upwards compatible with Ada 83.

However, no one should tell anyone that it is zero effort to move from Ada 83
to Ada 95. This is false, just as false as telling someone that it is zero
effort to move from one Ada 83 compiler to another Ada 83 compiler. Sure,
if a program has been *very* carefully written, and avoids implementation
dependent features, it may be highly portable, but the real world of large
scale applications is not in this category.

Ada programs are typically highly portable, but it is important not to
oversell this feature. I once heard the project director for the IBM
air traffic control system say that Ada 95 must guarantee that their
application move without changing a single line of code. The mere fact
that someone could state this obviously unrealistic requirement worried
me at the time, since it seems to me that anyone working with large
Ada applications should have a more realistic view.

Re: Ada News Brief

[Larry Kilgallen]

In article <dewar.845384950@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Keith said
> 
> "I'm not sure where this statement came from, but it's not quite correct.

As I read it, it came from a press release, so expectations should be low.

> 2. Bugs in the new Ada 95 compiler. As OCS systems pointed out, for at 
>    least some time to come, every Ada 95 compiler will have some bugs.

Folks who spend their life dealing with software quality will say that
every Ada 95 compiler will have bugs (defects) _forever_, just as with
any other program.  Priority is properly ascribed to those defects that
will be found by a user.  That is hard to measure in general, but as a
special case one has those defects that have already been found by a user.

> 4. Code that depends on implementation dependent details. For example, one
>    of our large customers had a heck of a time tracking down a "bug" which
>    turned out to be a case where a packed array of length (1 .. 32) of
>    booleans was mapped to an external hardware address. The Verdix compiler,
>    perfectly reasonably, loaded the entire 32-bit word to test one bit. GNAT
>    perfectly reasonably, loaded only the byte containing the bit to be tested.
>    Normally these two approaches would be identical, but their hardware could
>    not handle byte addressing for this address. We "fixed" GNAT to do a word
>    access in this case, but it was not of course a bug in GNAT.

Whose bug it is in cases like this depends on whether it was a documented
or undocumented hardware restriction.  I have run into some nasty problems
caused by failure to follow documented hardware restrictions, even by folk
who were involved in writing those restrictions !  Even for hardware
manufacturers who embrace GNAT as the solution to their Ada 95 "problem"
there may be a cultural bias against full disclosure or simply a lack
of internal documents laying out such problems.

> Ada programs are typically highly portable, but it is important not to
> oversell this feature. I once heard the project director for the IBM
> air traffic control system say that Ada 95 must guarantee that their
> application move without changing a single line of code. The mere fact
> that someone could state this obviously unrealistic requirement worried
> me at the time, since it seems to me that anyone working with large
> Ada applications should have a more realistic view.

At the "project director" level, I think this constitutes a "bargaining
position".  If this was a serious bidding situation, one might be quite
safe accepting such a restriction with a waiver count corresponding to
the amount of bad Ada 83 code found in the software. (I say that hoping
that "bad" is not one of those reserved terms like illegal, erroneous,
undefined, etc. :-).

Larry Kilgallen

Re: Ada News Brief

[Robert Dewar]

Larry said

"Whose bug it is in cases like this depends on whether it was a documented
or undocumented hardware restriction.  I have run into some nasty problems
caused by failure to follow documented hardware restrictions, even by folk
who were involved in writing those restrictions !  Even for hardware
manufacturers who embrace GNAT as the solution ...."

You misunderstood my example, this was a special home built (by the 
customer) bit of memory mapped hardware that happened to barf on byte
addressing. The Ada program deliberately or accidentally counted on
a particular sequence of code being generated that was consistent with
the particular requirements of this board.

No question whose bug this was - the customer's! Nevertheless operationally
it was a porting problem!

Re: Ada News Brief

[Dave Wood]

Larry Kilgallen wrote:
> 
> In article <dewar.845384950@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> > Keith said
> >
> > >                                                 ObjectAda
> > >for Windows includes the full Ada 95 core language and will
> > >compile all Ada 83 code without changes, according to the
> > >company.
> >
> > "I'm not sure where this statement came from, but it's not quite correct.
> 
> As I read it, it came from a press release, so expectations should be low.
> 

Er, well, rest assured that 'the company' made no such
claim.  The actual press release contained some suitable
adjective, like "virtually", which somehow was dropped
by the press.  But hey, if they're going to screw up our
press releases, I'm glad it's in our favor.  (At least
they didn't say:  ObjectAda includes the full Ada 95 core
language and will compile no Ada 83 code without changes...)

-- Dave Wood
-- Product Manager, ObjectAda for Windows
-- Thomson Software Products
-- http://www.thomsoft.com

Re: Ada News Brief

[Robert Dewar]

Dave Wood said

"Er, well, rest assured that 'the company' made no such
claim.  The actual press release contained some suitable
adjective, like "virtually", which somehow was dropped
by the press.  But hey, if they're going to screw up our
press releases, I'm glad it's in our favor.  (At least
they didn't say:  ObjectAda includes the full Ada 95 core
language and will compile no Ada 83 code without changes...)
"


Well I am not sure this is in your favor. I think it is important to educate
people away from the expectation that an Ada 83 switch will work perfectly
on their Ada 83 code. There are two reasons.

1. The switch from an Ada 83 to an Ada 95 compiler may involve changes in
implementatoin dependent choices (e.g. the behavior of representation 
pragmas). This is especially likely to be so if you are switching
front ends (VADS to GNAT, or DEC to Rational, or Alsys to TSP).

2. There are subtle changes in semantics, e.g. of overloading, which are
unlikely to be copied exactly. It makes no sense to have two overloading
algorityhms, where the only function of one of them is to implement
obscure Ada 83 rules that have been judged (a) undesriable and (b)
too obscure to worry about compatibility issues.

In addition, usually it is only worth trying to worry about correct Ada 83
rules, there seems little point (and it would be tough) to diagnose all
possible Ada 83 semantic errors.

One interesting criterion would be to see if a compiler can 100% validate
against 1.11 with its Ada 83 switch. GNAT certainly makes no such claim.

it is certainly true that advertisers and press are likely to be over
enthusiastic in their claims here (I have seem literature from more than
one vendor mislead on this point, not so much deliberately, but simply
as the result of abbreviation, advertising often gives false impressions
by not being able to give details).

Re: Ada News Brief

[Robert S. White]

In article <dewar.846422650@merv>, dewar@merv.cs.nyu.edu says...
...snip...

>1. The switch from an Ada 83 to an Ada 95 compiler may involve changes in
>implementatoin dependent choices (e.g. the behavior of representation 
>pragmas). This is especially likely to be so if you are switching
>front ends (VADS to GNAT, or DEC to Rational, or Alsys to TSP).
>
>2. There are subtle changes in semantics, e.g. of overloading, which are
>unlikely to be copied exactly. It makes no sense to have two overloading
>algorityhms, where the only function of one of them is to implement
>obscure Ada 83 rules that have been judged (a) undesriable and (b)
>too obscure to worry about compatibility issues.
>
>In addition, usually it is only worth trying to worry about correct Ada 83
>rules, there seems little point (and it would be tough) to diagnose all
>possible Ada 83 semantic errors.
>
>One interesting criterion would be to see if a compiler can 100% validate
>against 1.11 with its Ada 83 switch. GNAT certainly makes no such claim.
>

  But as it has been said before, just changing from one Ada 83
implementation to another can show up a lot of similar subtle 
incompatibilities.  Try moving from Tartan Ada 83 to Rational Apex 2.06
Ada 83.   Watch out for operator renames and not enough "use System;"'s.
It seems like I have had fewer problems with Gnat vs other "picky/tough"
Ada 83 compilers.

_______________________________________________________________________
Robert S. White                    -- an embedded sys software engineer
WhiteR@CRPL.Cedar-Rapids.lib.IA.US --long/cheap alternate I-net address
                                   -- support your public library!

RE: Ada News Brief

[Neil O'Brien]

On Sunday, October 27, 1996, Robert Dewar wrote...
[SNIP] 
> 
> Well I am not sure this is in your favor. I think it is important to
educate
> people away from the expectation that an Ada 83 switch will work
perfectly
> on their Ada 83 code. There are two reasons.
> 
> 1. The switch from an Ada 83 to an Ada 95 compiler may involve changes
in
> implementatoin dependent choices (e.g. the behavior of representation 
> pragmas). This is especially likely to be so if you are switching
> front ends (VADS to GNAT, or DEC to Rational, or Alsys to TSP).
> 

Just to clarify, Alsys and TSP are one and the same, we may have 3
front-ends associated with different technologies (RISCAda, AdaWorld and
ObjectAda) but 
the front-ends did not change because of a company name change.



=========================================================
Neil O'Brien			obrien@east.thomsoft.com
Customer Support		(617) 221 7320
Thomson Software Products

subscribe intel-objectada | unix-objectada <your email>
email to majordomo@east.thomsoft.com

"I went back to my hotel and intended to watch Tottenham -
but I fell asleep" - Arsene Wenger
. 

Re: Ada News Brief

[Michael Feldman]

In article <dewar.845384950@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:

[snip]

>Ada programs are typically highly portable, but it is important not to
>oversell this feature. I once heard the project director for the IBM
>air traffic control system say that Ada 95 must guarantee that their
>application move without changing a single line of code. The mere fact
>that someone could state this obviously unrealistic requirement worried
>me at the time, since it seems to me that anyone working with large
>Ada applications should have a more realistic view.

Hmmm - now that FAA seems to be moving toward using other languages, in
addition to Ada, I wonder if that PM would set the same requirement for
the subsystems written in... oh, say... C++.

Or was this just another subtle exercise in holding Ada to a much higher
standard (unrealistically so, perhaps) than other languages? 

Mike Feldman

Re: Ada News Brief

[Sandy McPherson]

Michael Feldman wrote:
> 
> In article <dewar.845384950@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> 
> [snip]
> 
> >Ada programs are typically highly portable, but it is important not to
> >oversell this feature. I once heard the project director for the IBM
> >air traffic control system say that Ada 95 must guarantee that their
> >application move without changing a single line of code. The mere fact
> >that someone could state this obviously unrealistic requirement worried
> >me at the time, since it seems to me that anyone working with large
> >Ada applications should have a more realistic view.
> 

So, Ada '95 has to implement a portable operating system? That's not
asking much is it? Seriously folks, the industry is in a bad way if
seemingly responsible people can spout such nonsense.

> Hmmm - now that FAA seems to be moving toward using other languages, in
> addition to Ada, I wonder if that PM would set the same requirement for
> the subsystems written in... oh, say... C++.
>

No, he would have *assumned* this is true for C++. It is amazing how
many people assume C++ is as portable as ANSI C. C++ is perceived as
being sexy and beautiful, and thus seemingly normal people can be
reduced to the level of infatuated teenagers. 

Why are the FAA moving to other languages? In Europe Ada is ATC language
number one. Did the FAA get burnt by an Ada development which went out
of control. Could someone supply me with references please?

> Or was this just another subtle exercise in holding Ada to a much higher
> standard (unrealistically so, perhaps) than other languages?
>

Probably.

-- 
Sandy McPherson	MBCS CEng.	tel: 	+31 71 565 4288 (w)
ESTEC/WAS
P.O. Box 299
NL-2200AG Noordwijk

Re: Ada News Brief

[Steve Jones - JON]

Sandy McPherson wrote:
> 
> Michael Feldman wrote:
> >
> > In article <dewar.845384950@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >
> 
> > Hmmm - now that FAA seems to be moving toward using other languages, in
> > addition to Ada, I wonder if that PM would set the same requirement for
> > the subsystems written in... oh, say... C++.
> >
> 
> No, he would have *assumned* this is true for C++. It is amazing how
> many people assume C++ is as portable as ANSI C. C++ is perceived as
> being sexy and beautiful, and thus seemingly normal people can be
> reduced to the level of infatuated teenagers.
> 
> Why are the FAA moving to other languages? In Europe Ada is ATC language
> number one. Did the FAA get burnt by an Ada development which went out
> of control. Could someone supply me with references please?
> 

Well I've worked on the NERC ATC project (The new posh UK system) and am
now working at Eurocontrol (A conglomeration of all of Europes Aviation
Authorities to create a unified approach).

NERC used C to do the GUI side, mainly because at the start there were
no offical X/Motif bindings.  Eurocontrol is at present using Ada in
totallity for its simulations (it has the bindings) but will be moving
more towards C++ as it moves to client server.  The problem is that
new technoligies come out first in C (now in C++) and projects have to
go that way.

As for why the old FAA project failed ?  From talking to people who
worked
on it (ie not managers or press releases). There were several horrific
design decisions made at early stages and an overestimation of just
what was physically possible and simple.

If you have a bad design no language would be better than another.

On the NERC side though about 90% of the bugs were in the C code of
which only about half would have been picked up if it had used
Ada.  The problem was also that GUIs tend to be very complex, although
no end-user will belive you, and you would expect more problems there.

Ada was absolutely essential however in making sure communications
between
systems was correct, I dread to think what would have happened
with 100 people working in C with interfaces with no size constaints.

Steve Jones

Eurocontrol Experimental Centre

Re: Ada News Brief

[Sandy McPherson]

Steve Jones - JON wrote:
> 
> Sandy McPherson wrote:
> >
[snip...]

> > Why are the FAA moving to other languages? In Europe Ada is ATC language
> > number one. Did the FAA get burnt by an Ada development which went out
> > of control. Could someone supply me with references please?
> >
> 
> Well I've worked on the NERC ATC project (The new posh UK system) and am
> now working at Eurocontrol (A conglomeration of all of Europes Aviation
> Authorities to create a unified approach).
> 
> NERC used C to do the GUI side, mainly because at the start there were
> no offical X/Motif bindings.  Eurocontrol is at present using Ada in
> totallity for its simulations (it has the bindings) but will be moving
> more towards C++ as it moves to client server.  The problem is that
> new technoligies come out first in C (now in C++) and projects have to
> go that way.
> 

On a project I worked on a few years ago, we used C for GUIs, precisely
because of the binding problem. Even if you have the bindings, the data
types used by X11 etc. are decidely Ada unfriendly. We limited the C
code to control of the GUI and the putting/getting of data into/from the
widgets. The rest was written in Ada

> As for why the old FAA project failed ?  From talking to people who
> worked
> on it (ie not managers or press releases). There were several horrific
> design decisions made at early stages and an overestimation of just
> what was physically possible and simple.
> 
> If you have a bad design no language would be better than another.
>

Aha, so Ada is the scapegoat?. Were the daft decisions in any way
related to a misunderstanding of the concepts present in Ada though?
 
> On the NERC side though about 90% of the bugs were in the C code of
> which only about half would have been picked up if it had used
> Ada.  The problem was also that GUIs tend to be very complex, although
> no end-user will belive you, and you would expect more problems there.
>

Did you use a good static analyser like QAC, and run time system like
Purify during your testing, these should identify most of the errors
that the Ada compiler and Runtime checks would find. What was the ratio
of Ada/C?. I can imagine that if vanilla C without lint were used, that
this would be the case, but with good support tools, this would seem
rather outrageous. Does this fact not worry you when you think about the
move to C++? Or, is C++ only for the simulators? If so this might be
acceptable, but the thought of a client server ATC system written in C++
gives me the creeps. 

I agree about GUIs, easy to use does not mean easy to build, usually the
contrary.
 
> Ada was absolutely essential however in making sure communications
> between
> systems was correct, I dread to think what would have happened
> with 100 people working in C with interfaces with no size constaints.
> 
C++ isn't any better.

-- 
Sandy McPherson	MBCS CEng.	tel: 	+31 71 565 4288 (w)
ESTEC/WAS
P.O. Box 299
NL-2200AG Noordwijk

Re: Ada News Brief

[Ken Garlington]

Keith Thompson wrote:
> 
> The statement on our Web site (see
> <http://www.thomsoft.com/products/ada/oa/oa2.html>) is:
> 
>     In addition, virtually all Ada 83 code will compile unchanged with
>     ObjectAda.
> 
> As always, I speak only for myself.

By the way, Peter Coffee wrote a glowing review of ObjectAda 7.0 for Windows
in the September 30, 1996 edition of PC Week. He did not include any statement
as to Ada 83 compatibility, however.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Ada News Brief

[Software Engineering News]

The statement from the 4 October Ada News Brief in question--"ObjectAda for 
Windows includes the full Ada 95 core language and will compile all Ada 83 
code without changes, according to the company."--was taken directly from the 
cited ComputerWorld source article by Justin Hibbard.  The full article can be 
found at 
http://www.computerworld.com/search/AT-html/briefs/9608/960807ada.html. 


In article <32635742.545C@lmtas.lmco.com>, garlingtonke@lmtas.lmco.com says...
>
>Keith Thompson wrote:
>> 
>> The statement on our Web site (see
>> <http://www.thomsoft.com/products/ada/oa/oa2.html>) is:
>> 
>>     In addition, virtually all Ada 83 code will compile unchanged with
>>     ObjectAda.
>> 

Re: Ada News Brief

[David Emery]

Steve Jones wrote:
>The problem is that new technologies come out first in C (now in C++)
>and projects have to go that way.

I don't understand this infatuation with 'latest and greatest' in 
safety-critical/mission-critical systems.  I sure wouldn't want my
life to depend on V1.0 of *anything*, particularly some commercial
product, developed using a commercial (i.e. first to market wins, and
we'll fix the bugs later) mentality.  

Is there *anyone* out there who tried to deliver anything using
MS-Windows 1.0?  I saw my first Windows spec in 1984, and that was for
Windows 2.0.  The consensus I've heard was that Windows didn't get
reliable until Version 3.1... 

				dave
--
<.sig is away on vacation>

Ada News Brief

[Becca Norton]

Ada News Brief
Week Ending: September 20, 1996

*****************************
MANAGING RUNTIME FAULTS
*****************************
Richard Riehle discusses runtime faults and Ada's exception 
handling capabilities in his latest article for the Ada 
column in Journal of Object-Oriented Programming. Riehle 
offers some background information on exception handling as 
part of a language design and uses Ada to provide examples 
and exercises on implementing exception handling. Riehle 
also discusses the importance and use of package Ada as part 
of, what he considers, one of the most significant Ada 95 
extensions. 

SOURCE:
Riehle, Richard. "Managing runtime faults," Journal of 
	Object-Oriented Programming. September 1996: 73-77.

*************
Ada 95 BOOKS
*************
The Journal of Object-Oriented Programming (JOOP) has 
recently published its annual object technology book listing 
... a great source for the latest in object-oriented 
programming. Keep in mind, however, that though the Ada 
object technology book listing is fairly comprehensive, it 
is not a complete list of all the new Ada 95 books. For a 
complete list of Ada books, look under Education/Training in  
the AdaIC's web site (http://sw-eng.falls-
church.va.us/AdaIC/ed-train).

SOURCE:
"The OT Book Listing," Journal of Object-Oriented 
	Programming. September 1996. 

********************************************
ORDERING THE DOD ACQUISITION DESKBOOK
********************************************
Information on the availability of the Defense Department's 
new Defense Acquisition Deskbook on CD-Rom was provided in 
the last Ada News Brief. Below is additional information 
(provided as a follow-up to the original Federal Computer 
Week article) on how to obtain the Deskbook on CD-Rom. 

All orders should specify ID Code (Desk); the product title, 
Defense Acquisition Deskbook on CD-Rom; and include payment. 
  By mail, customers should write to: Superintendent of 
Documents, P.O. Box 371954, Pittsburgh, PA 15250-7954. 
Payment may be made by check payable to Superintendent of 
Documents or charged to Visa, MasterCard or GPO deposit 
account.
  To order by phone, customers may call (202) 512-1800. To 
order by fax, call (202) 512-2250. Payment may be made by 
Visa, MasterCard or GPO deposit account.
  Another purchasing option is through one of 24 U.S. 
government bookstores located around the country.

Call Kathryn McConnell at (202) 512-1710 or Michael Bright 
at (202) 512-0108 for further questions about purchasing the 
CD-Rom.

SOURCE:
Letter from Wayne P. Kelley, Superintendent of Documents, 
Government Printing Office. Federal Computer Week, September 
2, 1996.

*******************************************************
The AdaIC's "Ada News Brief" is a compilation of summaries from
Ada-related articles in trade magazines, newsletters and press
releases. The AdaIC welcomes suggestions for and pointers to Ada-
related articles.
Contact the AdaIC at:

Ada Information Clearinghouse
P.O. Box 1866
Falls-Church, VA 22041
1-800/232-4211 or 703/681-2466
adainfo@sw-eng.falls-church.va.us
http://sw-eng.falls-church.va.us

To subscribe to the "Ada News Brief" electronic mailing list, send a
message to:
        listproc@sw-eng.falls-church.va.us
In the body of the message, write:
        subscribe adanews <your name>
To unsubscribe, write:
        unsubscribe adanews
No signatures please.