Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.sw.components
Subject: Re: maintenace and reuse
Message-ID: <130200015@p.cs.uiuc.edu>
Date: 20 Oct 89 16:40:30 GMT
References: <130200014@p.cs.uiuc.edu>
Lines: 46
Nf-ID: #R:p.cs.uiuc.edu:130200014:p.cs.uiuc.edu:130200015:000:2530
Nf-From: p.cs.uiuc.edu!johnson    Oct 19 06:37:00 1989


chittamu@umvlsi.ecs.umass.edu begs to differ with my claim that
reusing code requires understanding it, which sometimes
requires reading it.  He says that we should not have to read code, 
but only need to understand the function of the code.

This is an idealist's position.  Documentation is almost never
good enough.  Some people spend most of their time running
experiments on libraries trying to figure out what they do.
Others junk the libraries.  The systems that are most successful
for reuse usually make source available, because every so often
the users need to look at the code.  I know several companies that
refuse to buy libraries of components unless they get source.  It
might not be impossible to make libraries that are completely
useable only from the documentation, but it sure is hard.

An entirely different line of argument is that there is no difference
between programs and program specifications.  Either a program
specification is complete (it specifies everything of interest
about the program) or it is partial.  If it is complete, then it
is a program.  It may be written in a language that we don't
know how to compile efficiently, but that is just the inadequacy
of our compiler technology.  (I *know* about undecideability, and
it does not change my position.)  If it is partial then there will
be things we need to know about the program that is not in the
specification.

People who must put up with low-level languages can find it hard
to see that complete program specifications are just another way
of programming.  However, I program in Smalltalk at as high a level
as possible.  The result is that my programs look a lot like the
formal program specifications that I have read.  Of course, I don't
think that Smalltalk is as abstract as it should be, but it is one
of the better existing languages for programming at a very high level.

Smalltalk has lots of practical problems that can make it inappropriate
for commercial use.  However, it is possibly the best system for
software reuse.  In my opinion, everybody who is seriously interested
in reusable components should study Smalltalk to see what it did right.
The browser is an extremely important reason why Smalltalk is good for
reuse.  It assumes that code is readable.  I think this is important,
and people who expect to sell components without providing source
should ponder what they must do to overcome the fact that their users
won't be able to read their code.

Ralph Johnson -- University of Illinois at Urbana-Champaign