Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!rwallace
From: rwallace@vax1.tcd.ie
Newsgroups: comp.sw.components
Subject: Re: What is a reusable software component?
Message-ID: <6729.26c481cb@vax1.tcd.ie>
Date: 11 Aug 90 22:08:11 GMT
References: <27705@athertn.Atherton.COM> <533@helios.prosys.se> <27914@athertn.Atherton.COM>
Organization: Computer Laboratory, Trinity College Dublin
Lines: 43

In article <27914@athertn.Atherton.COM>, paul@athertn.Atherton.COM (Paul Sander) writes:
>>  These should be some way to store the B-tree on secondary memory, so
>>  that the data it contains could be reused in another program.
> 
> There are a number of features missing from this implementation that could
> be useful.  These include Anders' secondary storage capability (which is
> what B-trees are used most for), perhaps with multi user locking.  An
> implementation that uses shared memory, again with multi-user
> locking might be useful.  Still another that is implemented as a server
> that could allow data to be shared across machines would be useful.

As a matter of fact I think the module already has too much functionality. The
main reason I don't reuse software components (and I program in C++ which
combines the advantages of being the best OOP/software engineering language
around with the vast range of available C code) is that people who write
generic modules put in everything expect the kitchen sink. At the moment I'm
working on a project which requires screen handling, file handling via indexes,
and file and in-memory sort functions. There are commercially available
packages available to do all these things. I ignored them and wrote my own for
two reasons:

1. The commercial packages contained orders of magnitude more code than I need
for this project (a fourth-generation language for writing accounting
software). Their use would have expanded the size of applications produced with
the 4GL from around 100K to an estimated 400K (!!!).

2. To wade through all the junk and figure out how to make the commercial
packages actually work would have taken nearly as long as writing my own code.

The first problem can be solved by what I hope will be the next generation of
super-optimizing compilers that can examine all modules of a project
simultaneously and eliminate code that will never be used e.g.

main () { printf ("Hello, World!\n"); }

would end up as 100 bytes because the compiler would eliminate all the code
from printf to handle numbers etc.

The second problem requires an attitude change.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@vax1.tcd.ie