Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eos!eugene
From: eugene@eos.UUCP (Eugene Miya)
Newsgroups: comp.sw.components
Subject: Re: a comment on Using components (also LONG)
Message-ID: <3579@eos.UUCP>
Date: 10 May 89 18:17:29 GMT
References: <11293@bloom-beacon.MIT.EDU>
Reply-To: eugene@eos.UUCP (Eugene Miya)
Organization: NASA Ames Research Center, Calif.
Lines: 126

I'll read this group for a while.  It was beginning to sound like an
Ada buzzword group for a while.  (Sorry, I once came from big software
projects, and I'm feeling punchy.)

In a nice article <11293@bloom-beacon.MIT.EDU> tada@athena.mit.edu 
by Michael Zehr:

>Most of the discussion so far seems to be directed at retrieving
>components, but there's been very little said about using them.
>
>background: i haven't done any programming in ADA, so if there's a
>definition of component that only applies to ADA, i don't it.  i'm
>basing this on my "feel" of component -- namely a group of code that's
>intended to for reuse.  

Any tool which is so specialized that it can't be used with any other
language has serious problems.  It would deserve to die quietly
in a corner (there are exceptions of course).  The problem with SOME of
the Ada people (those that don't code, but manage) is that they expect
their programmer's language to solve all of THEIR problems.

>my experience so far has been that the more general a component is, the
>slower it runs.

This is part of the reason why Unix developed.  No Unix flame wars please.
See my defense below.  The point is we see that performance is sort of
the main reason for using computers (not completely).

>for another example, some languages have arrays as their basic data
>unit. "+" becomes an array operator.  but if all you need to do is add
>two scalar quantities, you're hit with a performance penalty.

Small point of order: this is typically a compilation, not an execution
time function, you you are typically not penalized for this.  (Called
overloading, neat stuff.)

>so far, the trend has largely been towards larger and larger components:
> ..... abstraction from s/w to h/w
>
>hardware trends have been similar: emergence of CISC
>
>but recently, the hardware trend has reversed -- use very simple instructions
>(i'm referring to RISC of course.)

You are not alone in thinking about this.  The problem is: How to
build something that has never existed before?  I am refering to tools.
The problem is the management of complexity.  We are discussing this
in a local ACM/SIGGRAPH group, we call it TIGSV: Technical Interest Group
in "Scientific Visualization" [here's a buzzword I can introduce]....

Components are one thing, reuse is another.  There is the issue of
making them and maintaining them.  In the Beginning, there were scientific
libraries (seems the reuse-people forgot about these, oh well, how else
to go from stone wheel to steel-belted radials).  Now, these were good.

The came Unix and its software tools philosophy.  I began as an MVT hacker.
And at first it was strange to me.  People mistook the command (filenaming)
as bad and discarded without seeing and understanding the functionality
[BTW: LISP has goods as well, but not as wide spread].  They also created
other problems based on their closed, non-flexible  thinking about computers.

It was a philosophy of minimalism, but it was a simple, but very subtle,
logical next step.  See to use libraries, you had to edit, compile,
and then link a call to usage.  Unix introduced co-routines and parallelism
for the masses (and other things).  So instead of edit, compile, link, run,
you did:
	troff filename or to an extreme:
	chem filename | pic | refer | tbl | eqn | troff
Yes you learn a lot of commands, but then we want to do lots with computers.
You can learn lots of little commands or learn lots of little options.
But each of the above only takes a few minutes to learn (except troff
or tex, or Scribe, etc.... ok a generalization) [this is the learning problem]
But getting back, its not just text.  It graphically started as
	graph | plot
but if you wanted more you could do
	spline | graph | plot and so on.
This is actually better documented in two of CACM's Jon Louis Bentley
Programming Pearls column a couple of years back.  Unfortunately neither
appeared in the books PP or More PPs.  The one column was entitled:
Little Languages (Aug 86) and the other was a face off by two guest
Oysters: Don Knuth and Doug McIlroy (June 86).  The latter column is the more
important.  I recommend them if you have not read them.

Then there was the Xerox/SRI ARC/Apple/NeXT line of work.  This looks
good.  How can 10K words say it? ;)

So what's next?  THAT is where the real challenge is.  I think it
will have to deal with parallel architectures.  But there are some major
intellectual hurtles there.  Using Sequents and Crays and Connection Machines
are kind of neat in this regard.  Its the limits of Silicon.  Its only
going to get harder before it gets easier.

>saving time building the application is more important than
>reducing the running time of the application.  
>but my experience on applications has led to the conclusion that a lot
>of performance is being sacrificed for the decrease in application
>building time.
>
>do others agree that this is a problem in the software industry, or it
>is just me?  if it is a problem, how should we face it and fix it
>before it becomes worse?
>
>(sorry for the length of this)

True. (on time and loss of some performance, by faster machines.)
You cannot expect gains in performance and functionality at this time
with combined gains in both hardware and software.  Just ask Xerox
or Apple or NeXT.  There are many similar analogies in the physical world.

The real question is how much a user, builder is willing to change.
Change is what software is all about.

You have no reason to be sorry,  you only get rid of those short-sighted,
short-attention spanned people which our country is so notorious for
producing (bad managers). ;)

Longish signature follows "Type 'n' now"

Another gross generalization from

--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
  resident cynic at the Rock of Ages Home for Retired Hackers:
  "You trust the `reply' command with all those different mailers out there?"
  "If my mail does not reach you, please accept my apology."
  {ncar,decwrl,hplabs,uunet}!ames!eugene
  				Live free or die.