Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!mcnc!duke!romeo!gm
From: gm@romeo.cs.duke.edu (Greg McGary)
Newsgroups: comp.sw.components
Subject: Re: a comment on Using components (shorter)
Message-ID: <14479@duke.cs.duke.edu>
Date: 12 May 89 01:45:00 GMT
References: <11293@bloom-beacon.MIT.EDU> <3579@eos.UUCP> <1080@ginosko.samsung.com> <3594@eos.UUCP>
Sender: news@duke.cs.duke.edu
Reply-To: gm@romeo.UUCP (Greg McGary)
Organization: Duke University CS Dept.; Durham, NC
Lines: 29

In article <3594@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes:
>... the really neat thing I thought
>about Unix software tools was they kept much of the library function
>while also being executable programs.  There was the spline program
>and the spine function.

Yes, this is a `really neat thing' but not something I usually think
of as a feature of UNIX.  If anything, this isn't done anywhere nearly
often enough.  The contents of libc probably contain only 5-10% of
commonly useful funtions that are reimplemented or cut/pasted all over
the system.  The integrated environments like lisp and smalltalk are
better for reusability, since the fire-wall that separates programs and
library-functions isn't present, but even these suffer from re-invention
of the wheel when programmers don't bother to research existing code.

Too often I've wanted to lift a function or two out of some random UNIX
utility only to find that the interface was all boogered up with
references to global data structures.  To this day, I'm shocked at how
many programmers blithely put pages full of global variables in their
programs...

A few years ago I found a real jewel.  (I think it was System-V.0) 
The library function getwd(3) was implemented by calling
popen("/bin/pwd", "r")!  Long live US{G,DL}.

-- Greg McGary
-- 4201 University Drive #102, Durham, NC 27707       voice: (919) 490-6037
-- {decvax,hplabs,seismo,mcnc}!duke!gm                 data: (919) 493-5953
--                                  gm@cs.duke.edu