Re: Ada

[rowe@cme.nist.gov (Walter Rowe)]

Ignore that last one ... got trigger happy ...
----------------------------------------------------------------------
>>>>> On 15 Nov 89 16:06:41 GMT, billwolf@hubcap.clemson.edu (Bill Wolfe) said:

billwolf> This is blatantly false; consider the November 1988
billwolf> article in IEEE Software ("Large Ada projects show
billwolf> productivity gains"):

billwolf> [...irrelevant text deleted...]
billwolf> on the project was counted only once.  Roughly 13 percent of
billwolf> the delivered software was reuseable.

Uhmmm ... correct me if I'm wrong here, but if a project is well
designed (ie. module specs are written to be general), I think there
would be a higher degree of re-usability for those modules, regardless
of the language used.  That's the purpose of writing generalized code.
Any good computer scientist/programmer knows that, right?

Imagine having to write sin(), cos(), etc, for every application you
needed them for.  This would of course be ludicrous, so those in the
know wrote good, generic routines to handle these functions and now
you take them for granted.

What I'm trying to say is that re-usability is not necessarily an
attribute of the programming language being used, but more likely it
is the result of using good system design techniques.  Who cares if
its C++, Ada, C, or Pascal?  If you approach the design correctly,
your solution will be general enough so as to apply to the greatest
number of variations of the same problem.  Thats what re-usability is
all about, isn't it?  Not re-inventing the wheel?

billwolf> Sounds like a continuing *success* to me ...

Sure, but so is Pascal (originally designed as a learning tool), but
its not highly used outside of Academia just like Ada is not highly
used outside of DoD.  Ever wonder why?
   
billwolf> A prime example is Unix; the current POSIX effort aims to
billwolf> standardize 1960's technology, thus resulting in a "lowest
billwolf> common denominator" which locks users into obsolescence.

I disagree.  Its not locking into obsolescence.  Its forcing one to
meet only a minimum set of requirements, which allows a maximum amount
of flexibility above and beyond those requirements.  As long as you
meet these minimum requirements, you still have the freedom to enhance
UNIX any way you see fit.  They aren't restricting you to these, but
saying that you must provide at least these things.

billwolf> Modern programming languages provide a variety of features
billwolf> to support development and maintenance of software products.
billwolf> These features include strong type checking, separate
billwolf> compilation, user-defined data types, data encapsulation,
billwolf> data abstraction, generics, flexible scope rules,
billwolf> user-defined exception handling, and concurrency mechanisms.

I have to agree with Bill on this point: more languages ARE beginning
to evolve into useful tools for productivity, rather than learning
tools, or tools intended for specific applications.  However, I think
in order to be most productive and efficient for a given application,
a language still must cater to that application to some extent (ie.
COBOL for record transaction processing, C for systems programming,
etc).

> [...] There is the August 21 89 issue of Government Computer News
> describing the problems which the huge FAA Advanced Automation
> System is having due to IBM Ada implementations and tools (or lack
> thereof).

billwolf> Are you saying that this is the fault of the *language*, or
billwolf> of IBM?

More than likely its IBM, although most of their projects seem to come
out of a committee, and in that respect, draw a striking resemblance
to Ada.  So, possibly both are at fault since Ada was designed by a
committee, too.  I think the basic point being made is that too many
hands in the pot spoil the soup, and I tend to agree with this.  Its
good to get outside opinions so that one can be as objective as
possible, but I still think that fewer people can supply a much more
rational decision.

> the programming style being promulgated by DOD for Ada [descriptive
> variable names] is anti-conducive to the stated goal of readability;  

billwolf> To C hackers, who are accustomed to single-letter variables,
billwolf> yes.  Software engineering specialists tend to have the
billwolf> opposite perspective.

Admittedly, I fall into the C hacker category, but I think Ted makes a
valid point here.  I'd much prefer to shuffle through a few pages of
documentation at the top of a print-out than have to look at unsightly
long variable/procedure/function names.  I support giving variables
meaningful names, just not unsightly long ones.

If the docs are good at the top of a file are good (ie. they clearly
and concisely convey the concept of what this code is suppposed to
do), then you shouldn't have to clutter the code with paragraph long
names.  You're trying to infer the logic being applied, not the
details of the individual statements (for alone they mean nothing
anyway).

billwolf> Bill Wolfe, wtwolfe@hubcap.clemson.edu

Walter Rowe, rowe@cme.nist.gov
---
My opinions are my own, and bare no reflection of the opinions
of the United States Government.