🚀 go-pugleaf

From scotth@boulder.Colorado.EDU (Scott Henninger):
> The ADT approach has been around for a long time, so I ask you, 
> why is it not currently practiced?  Don't tell me that training 
> is the answer - programmers are already trained to design and 
> implement ADTs.

   Consider some of the things that have happened within the
   last few years: there is now a language whose definition
   is an ANSI and international standard which prohibits subsets
   and supersets (ensuring portability), which provides *secure*
   facilities for the construction of quality ADTs (and by that
   I mean limited private types, which can be built such that
   instances of the ADT will maintain consistency in the presence
   of multitasking, and will in fact process requests in parallel
   while ensuring serializability and recoverability, etc. etc.),
   and for which second-generation highly optimizing compilers
   are now widely available.  This language is also saving lots
   of money in practice (as described in the IEEE Software article
   of November 1988, "Large Ada projects show productivity gains"),
   which is stimulating considerable growth in its use.  Finally,
   companies have developed catalogs of components for this language
   (Wizard Software, lib systems, etc.) and are actively selling them 
   into the user market.  In short, the conditions in which the ADT
   approach can thrive are now being established.

   You want results?  From the article cited above: Magnavox did a
   Ada project at the 1.2-million-line level in which reuseable
   software NOT developed on the project was not counted at all,
   and reuseable software developed on the project was counted only
   once; the productivity was 550 lines per man-month for the systems
   software and 704 lines per man-month for the applications software.
   The average productivity found in a productivity consultant's database
   of 1,500 projects at the 1.2-million-line level was only *77* lines per
   man-month.   Reuse saved 190 man-months (9%) of effort and reduced
   the schedule by two calendar months (4%); Magnavox expects to increase
   the reuse rate to 25% on the next project, and believes that a reuse
   rate of 50% is possible.

   Bottom line: Reuse is now proving itself.  We are making it happen.

   (By the way, reuse is going to be a major topic at the Tri-Ada '89
   conference up in Pittsburgh, and I will be in an excellent position
   to give recent results as soon as I get back from the conference.)


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
   

|>From scotth@boulder.Colorado.EDU (Scott Henninger):
|> The ADT approach has been around for a long time, so I ask you, 
|> why is it not currently practiced?  Don't tell me that training 
|> is the answer - programmers are already trained to design and 
|> implement ADTs.
|
|>From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
|   You want results?  From the article cited above: Magnavox did a
|   Ada project at the 1.2-million-line level in which reuseable
|   software NOT developed on the project was not counted at all,
|   and reuseable software developed on the project was counted only
|   once; the productivity was 550 lines per man-month for the systems
|   software and 704 lines per man-month for the applications software.
|   The average productivity found in a productivity consultant's database
|   of 1,500 projects at the 1.2-million-line level was only *77* lines per
|   man-month.  Reuse saved 190 man-months (9%) of effort and reduced
|   the schedule by two calendar months (4%); 

Although I am truly happy these managers were able to find ways to claim
productivity gains (and probably get promotions for it), we should be
skeptical of these numbers for many reasons, two of which follow:

  1) Cobol could probably do better by the lines-of-code measurement. 
     In other words, just because more lines of code were developed
     doesn't mean that productivity was enhanced.

  2) Different projects have different dynamics.  It is a fallacy to
     compare man-months of projects that simply had the same number of
     lines of code.  First of all, 1) still applies.  Secondly, the
     difficulty of the domain is not accounted for.  Thirdly, the skills
     of the programmers is not accounted for; ad infinitum.  You can't
     compare apples to oranges! 

|   Magnavox expects to increase the reuse rate to 25% on the next
|   project, and believes that a reuse rate of 50% is possible.

General Electric claimed the same thing in the 60's.  It never
materialized.

The bottom line is that there is a distinct possibility that these
results are contrived by self-serving interests.  I think you're right
in stating that reuse is making headway, but it is extremely small, and
is certainly much smaller than the results you cite indicate.  

I characterize it as a monkey climbing a palm tree to reach the moon. 
He sees he is making progress and begins to make wild claims. 
Unfortunately, he soon reaches a dead end.  I claim the dead end in
software reuse is cognitive overload.  It will take thousands or
millions of components to make a truly useable software reuse
environment.  There is no way that a human can keep track of what is
available at that kind of scale.

The cognitive overload also comes in understanding what a component does
for you.  Do you realize how hard it is to get novice programmers to
understand what a stack does?  And this is one of the simplest
constructs in computer science.  Just think of training someone to
understand 1000 ADTs (that are much more difficult to understand than
stacks) to the point that he can (re)use them. 

I also must emphasize that the problems of reuse ARE LANGUAGE
INDEPENDENT.  Even with all of the religious followers of ADA out there,
you will never in a million years convince me that ADA is anything more
than trivially different from Pascal, C, Algol, etc.

|   [...] there is now a language whose definition is an ANSI and
|   international standard [...]

Emerson said that "a foolish consistency is the hobglobin of little
minds...".  In this spirit, I would claim that we do not know enough
about human factors in programming (note that I did not say programming 
*languages*) to point to standards as a means to claim that your favorite
language is the best. 


-- Scott
   scotth@boulder.colorado.edu

In article <11963@boulder.Colorado.EDU> scotth@boulder.Colorado.EDU (Scott Henninger) writes:
>  I claim the dead end in
>software reuse is cognitive overload.  It will take thousands or
>millions of components to make a truly useable software reuse
>environment.  There is no way that a human can keep track of what is
>available at that kind of scale.

  The trick is to let the computer help with this, and find a
reasonable way to organize the components.  There were those who
claimed in the 17th century that widespread printing would lead to a
disaster--libraries would be overloaded and it would be impossible to
find the texts on a given subject.
  What happened?  Library science started appearing.  It tackles
exactly the same problem which will occur with re-use in software
engineering: millions of components, all doing slightly different
things.  The library on campus here has somewhere between 1 and 2
million books; yet, when I go to look for a book on finite automata, I
can find a set of them easily.  We need to develop a similar
organizational technique for software components.

>The cognitive overload also comes in understanding what a component does
>for you.  Do you realize how hard it is to get novice programmers to
>understand what a stack does?  And this is one of the simplest
>constructs in computer science.

  Yes, but it gets easier to understand new data structures as one
goes along.  I've only been programming for 8 years or so, but I can
look at a data structure description in Knuth and understand it in an
hour or two (as a general rule :-).  I can even define what I need
("a priority queue with fast removal of the first element and a fast
way to merge two queues") and go find a data structure for it.  Of
course, there aren't enough books which describe the structures....

>I also must emphasize that the problems of reuse ARE LANGUAGE
>INDEPENDENT.

  Definitely true.  I reuse a good chunk of my Pascal code...just
change the names of the structures and key fields.  Now, a nice way to
do this automatically (without manual editing) would be nice--that's
what Ada gives you.  But the basic problem isn't going through and
making the minor fixes, it's figuring out what you can reuse and how
to do it.

[ stuff about why "standard" doesn't necessarily mean "best" ]

  I agree and disagree with this, I guess.  Having a standard is good
because it means that components are more portable.  Right now, I have
a lot of Pascal libraries using VAX Pascal-specific constructs (i.e.
modules); moving these to other systems is possible, but quite a bit
of work.  On the other hand, I can move Ada code around without any
problems (barring compiler bugs/features :-).
  Using the library analogy, most of the books here are in English.
There are some in German, Spanish, and other languages.  If someone
wants to take the time, they can translate them, and it will take less
effort than writing them from scratch.  On the other hand, if I knew
how to read all the languages in the library, I could use every book
as a potential source.
  Similarly, I think more attention should be paid to interfacing
different languages together.  Calling Pascal or FORTRAN code from Ada
ought to be trivial, as long as certain Ada-specific semantics (such
as exception handling) are handled right.  Right now, I only know of
one operating system (VMS) which lets me mix languages freely without
worrying too much about their idiosyncrasies.  It might be nice to
have more development environments which handle multiple languages.
  Just my thougts....
   
+----------------------------------+------------------+
| Anton Rang (grad student)        | rang@cs.wisc.edu |
| University of Wisconsin--Madison |                  |
+----------------------------------+------------------+

"You are in a twisty little maze of Unix versions, all different."

As a change from the GC wars, let's talk about how you might want to use
components in a kinder, gentler, software development environment.

In article <11963@boulder.Colorado.EDU> scotth@boulder.Colorado.EDU (Scott Henninger) writes:
> ... [GC dialectic omitted] ...
>  It will take thousands or
>millions of components to make a truly useable software reuse
>environment.  There is no way that a human can keep track of what is
>available at that kind of scale.
>
>The cognitive overload also comes in understanding what a component does
>for you.  Do you realize how hard it is to get novice programmers to
>understand what a stack does?  And this is one of the simplest
>constructs in computer science.  Just think of training someone to
>understand 1000 ADTs (that are much more difficult to understand than
>stacks) to the point that he can (re)use them. 

OK, so maybe we are at the point of talking about software as an
engineering discipline rather than a branch of applied mathematics, or a
form of handcraft.  How does an electrical engineer deal with the thousands
of IC and other types of components he must choose from?  He consults a
(set of) databooks(s).  How does a mechanical engineer choose from among
the standard components which his plant stocks or manufactures?  He
consults a computer database.

What we need to develop now are ways to think about software components
which can be translated into rules for specifying components both before
construction and afterwards.  This is the basic enabling technology for a
marketplace in software components.  A producer of a component can enter such a
specification into a database; a consumer can create such a specification
to retrieve a set of components which are candidates for use in his
application.  This will allow databases of components to be built up and
access to the components can be given, bought, sold, traded, what-have-you.
An executable description of a component could be provided for the consumer
to use in simulations; if it worked well, the implementation could then be
bought.  I won't spend a lot of time predicting the way this could develop
just now; let's see what others have to say.

>I also must emphasize that the problems of reuse ARE LANGUAGE
>INDEPENDENT. 
In fact there are many good reasons why software development should be
language independent, at least insofar as design goes.  I realize that this
is a hopelessly idealistic attitude for the way things are done today :-), but
it's worth working towards.  Certainly the specification of a component can
easily ignore the implementation-level detail of what language it will be
implemented in.  In fact, there's no reason why the specifier needs to
know if will be implemented once in a given language, or many times, in
many different languages.  And there should be no reason for a consumer to
consult the implementation of a component until specifications have led him
to the right design.

> Even with all of the religious followers of ADA out there,
>you will never in a million years convince me that ADA is anything more
>than trivially different from Pascal, C, Algol, etc.
>
And even if it were superior for many things, it
    a) isn't likely to be superior for all applications.
    b) won't remain superior in the face of new applications and evolving
     software technology (Fortran was JUST GREAT for it's time; Fortran 9x
     is an attempt to keep it that way; so does that mean we will all use it?)
    c) isn't going to be used by everyone just because it is superior (after
     all many technically inferior products dominate their markets; we rational
     types hate to admit that).
So there will never be a single programming language for all (or probably
even a majority) of all applications.  We need to find solutions to our
problems which do not depend on the most recent "best programming language."

Bruce Cohen
brucec@orca.wv.tek.com
Interactive Technologies Division, Tektronix, Inc.
M/S 61-028, P.O. Box 1000, Wilsonville, OR  97070

Let us concede for the sake of argument that eventually there will be
catalogs of software components and even an electronic/expert
retrieval system and tools to quickly tailor general components to
specific uses.

How will this be commercialized? or will it? Hardware components are
sold by the piece after the piece has been selected. Given the almost
negligible cost of replication of software will this be a viable
mechanism for software components?

Large libraries are often funded by public or not-for-profit
organizations so cost recovery is not a problem. Will the government
step in and create a National Software Library? How will we set the
prices for software components in this not-really-a-market situation?
Would foreign companies/individuals have access to our National
Software Library?

Will large corporations develop proprietary libraries that are used to
a competitive advantage over smaller companies?

Are software components intellectual property? While you could clearly
copyright a particular implementation of a an ADT, it seems unlikely
(and I'll venture undesirable as public policy) to allow someone to
patent an "abstract" data type. How will owners of for-profit software
component catalogs protect their investment?

-- 
David Callahan  (david@tera.com, david@june.cs.washington.edu,david@rice.edu)
Tera Computer Co. 	400 North 34th Street  		Seattle WA, 98103