Another One Bites the Dust!

Another One Bites the Dust!

[Bob Wells #402]

G'day,
I've just heard that the Swedish military is not going to proceed
with an Ada version of the tactical terminal that they had ordered.

Siemens AS had built such terminals for the Norwegan Army using
SDL and C. They then won the contract to build a modified version
of the terminal for the Swedish Army using Ada.

The schedule was such that the delivery of the prototype, upgraded
to the new Swedish spec. but also using SDL and C, was due for
evaluation in August this year. It turns out that the prototype
worked so well that the Swedes have said not to bother with the Ada
version, they are happy with the performance of the SDL/C version!

Oh well, I was looking forward to going back up to Oslo! )-: I guess
as Malcolm said "Life wasn't meant to be easy!"

@                   --------
@          ////  - ( G'day! )
@         (o o)     --------
@ ----oOO--(_)--OOo--------------------------------------------------------
  Bob Wells               "Si hoc signum legere potes, operis boni in rebus
                             latinis alacribus et fructuosis potiri potes."
@ INTERNET: wel@eurocontrol.de                 Compu$erve:      100272,3004
@ The Ada WWW Server is http://lglwww.epfl.ch/Ada/                 Team Ada
@ For exciting Ada info enter 'finger wel@s4ecawel.eurocontrol.de'

Re: Another One Bites the Dust!

[Robert Dewar]

Prototyping an application that is eventually to be written in Ada by
using C or C++ is not uncommon, but it is almost always a bad idea. First
of all, C (or even Ada for that matter) is much too low a level language
for prototyping. If you are serious about prototpying you should be using
appropriate prototyping tools.

Secondly, the phenonemon that was just reported in this thread is a danger,
I don't mean a danger to Ada, I mean a danger to the customer. The fact
that something works fine is just NOT GOOD ENOUGH. You would think that
people would realize this by now, but somehow the lesson never seems to
sink in.

The fact that something works gives no indication whatsoever of the quality
of the code, or its maintainability or long term reliability, or of the
life cycle costs that will be incurred in maintaining it.

Now of course Ada does not *guarantee* an improvement in these areas, but
it helps, and one certainly assumes that the reason that Ada is spec'ed (in
an environment where the choice exists) is that a judgment has been made that
these factors are important. It is probably also true in many environments
that with Ada it is easier than C to get a program working in the first place,
but that's not usually the primary justification for the use of Ada.

So it seems quite short sighted to choose Ada, and then be seduced by
"but it's working fine now" observations.

Of course if circumstances have changed to affect the validity of the
original judgment to use Ada, that's fair enough. FOr example, if Ada
was sold on the basis "you'll never have a chance of getting it working
in C", then clearly the observation is significant, but I certainly hope
that Ada is NOT sold on such a transparently bogus basis, it is obviously
*possible* to get anything working in any language, even in assembler for
that matter.

Re: Another One Bites the Dust!

[David Weller]

In article <9410281126.AA08984@eurocontrol.de>,
Bob Wells #402  <wel@EUROCONTROL.DE> wrote:
>I've just heard that the Swedish military is not going to proceed
>with an Ada version of the tactical terminal that they had ordered.
>
>[snip]
>The schedule was such that the delivery of the prototype, upgraded
>to the new Swedish spec. but also using SDL and C, was due for
>evaluation in August this year. It turns out that the prototype
>worked so well that the Swedes have said not to bother with the Ada
>version, they are happy with the performance of the SDL/C version!

I, for one, am glad they didn't convert it into Ada.  The issue
appears (to me) to be cost.  And this appears to be a genuine case of
where it would be more costly to use Ada.  Remember, not _every_
situation calls for Ada, even when it might appear so.  

(No, I haven't turned into a "Pod Person" like from "Invasion of the
Body Snatchers" :-)


-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Another One Bites the Dust!

[Bob Wells #402]

Robert Dewar <dewar@CS.NYU.EDU> writes

> Prototyping an application that is eventually to be written in Ada by
> using C or C++ is not uncommon, but it is almost always a bad idea. First
> of all, C (or even Ada for that matter) is much too low a level language
> for prototyping. If you are serious about prototpying you should be using
> appropriate prototyping tools.
>

Sorry, I must have not been clear enough in my descriptions. Siemens AS builds
such terminals for the Norwegan Army using C. They are production items. Sweden
wished to have something similar, but with slightly different functionality. To
speed up the development cycle, they agreed to conduct field tests using a
modified version of the Norwegan, C based terminal.

No prototyping of the application was done in the sense you imply in the above
paragraph apart from the originsl development work carried out in SDL (Z.100).

> Secondly, the phenonemon that was just reported in this thread is a danger,
> I don't mean a danger to Ada, I mean a danger to the customer. The fact
> that something works fine is just NOT GOOD ENOUGH. You would think that
> people would realize this by now, but somehow the lesson never seems to
> sink in.
>

Christ, can we get you on the quiz show Mastermind? Next contestant Robert
Dewar, subject "The Bloody Obvious!" (Thanks Basil) Give them some credit.
I'm sure they're not going to release, or the customer accept, something that
is going to be calculating fire control orders without doing at least *some*
testing!

> The fact that something works gives no indication whatsoever of the quality
> of the code, or its maintainability or long term reliability, or of the
> life cycle costs that will be incurred in maintaining it.
>

What about when the "something" is just a slightly modified version of a
production item which has been manufactured for several years?

> Now of course Ada does not *guarantee* an improvement in these areas, but
> it helps, and one certainly assumes that the reason that Ada is spec'ed (in
> an environment where the choice exists) is that a judgment has been made that
> these factors are important. It is probably also true in many environments
> that with Ada it is easier than C to get a program working in the first place,
> but that's not usually the primary justification for the use of Ada.
>
> So it seems quite short sighted to choose Ada, and then be seduced by
> "but it's working fine now" observations.
>

Does this include the Norwegan Army who have been seduced for several years now
with their working system?

> Of course if circumstances have changed to affect the validity of the
> original judgment to use Ada, that's fair enough. FOr example, if Ada
> was sold on the basis "you'll never have a chance of getting it working
> in C", then clearly the observation is significant, but I certainly hope
> that Ada is NOT sold on such a transparently bogus basis, it is obviously
> *possible* to get anything working in any language, even in assembler for
> that matter.

Why would anyone, independently go off and, in parallel with the Ada work,
develop another system in C just to prove that the statement "you'll never
have chance of getting it working in C" is wrong?

Is this not the problem we now face? "Oh you don't want to use Ada. The compiler
s
are bad and very buggy. There are very few tools available, and besides when we
did some benchtests in 198[1234] the generated code was very slow compared to th
e
equivalent FORTRAN code!" Sound familiar?

@                   --------
@          ////  - ( G'day! )
@         (o o)     --------
@ ----oOO--(_)--OOo--------------------------------------------------------
  Bob Wells         "The marvels of today's modern technology include the
                     development of a soda can, when discarded will last
                     forever ... and a $7,000 car which when properly cared
                     for will rust out in two or three years."
@ INTERNET: wel@eurocontrol.de                 CompuServe:      100272,3004
@ The Ada WWW Server is http://lglwww.epfl.ch/Ada/                 Team Ada
@ For exciting Ada info enter 'finger wel@s4ecawel.eurocontrol.de'

Re: Another One Bites the Dust!

[Robert Dewar]

well the "bloody obvious" sometimes escapes people, and apparently continues
to do so:

  NO AMOUNT OF TESTING CAN GUARANTEE MAINTAINABILITY

Indeed, I trust that this *is* BO!