Unix/C program modularity

[Kurt Papke]

In article <1898 at umcp-cs.UUCP> chris at umcp-cs.UUCP (Chris Torek) writes:
>[This is in response to article <637 at dicomed.UUCP> by
>papke at dicomed.UUCP (Kurt Papke).]
>
>Perhaps I should not speak of it, since I have not been involved in
>any of the actual coding, but I believe I know of a counterexample.
>The Center for Automation Research (nee Computer Vision Laboratory),
>umcp-cs!cvl, has a very large body of reusable code:  the CVL
>picture library.  I do not, however, know much about this, so I
>well be wrong.

You may be, but its probably my fault: one point I may not have made
sufficiently clear is that the domain of applications programs I was
referring to is that of "commercial" code, i.e. that used in a production
environment running 24 hours/day, with no "computer operator" intervention.
>From my standpoint, an R&D lab makes a poor counterexample because the user
is assumed to be "computer-literate", manipulating the programs directly.

>But in any case, I think you have, as the saying goes, lost sight
>of the forest for the trees.  Why *should* Unix programmers write
>reusable code for each program?  Instead, or perhaps in addition
 ===============================
Why indeed ??  Because many of us have to write code fragments that
someday may not exist in the Unix environment.  For instance at Dicomed
(and by the way I'm not proud of this) we are currently selling systems
that run under RSX-11m, MS-DOS, Xenix, and RMX-86.

>but more importantly, Unix programmers should---and at times do---
>write reusable *programs*.  The very `Unix Philosophy' of which
>you speak is that you should create a set of tools which can be
>used together to solve many problems, though each tool solves only
>a subset of any one problem.
>
>To give an example, however contrived or even erroneous---as I
>mentioned, I do not work for CfAR---consider taking a set of picture
>files, performing some algebraic transformation on each pixel value,
>applying histogram equalization, then halftoning and printing on
>an Imagen laser printer:
>
>	for i in *.pict; do
>		lop "your operation here" < $i | histeq | ht | pi |
>		qpr -q imagen-imp
>	done
>
>(I have made up some of these program names; CVL people may correct
>me if I have important details wrong.  `lop' stands for Local
>Operation on Picture, by the way.)  If instead you need to display
>one of these on the Grinnell:
>
>	lop "your operation here" < foo.pict | histeq | ht | put "params"
>
>or without halftoning:
>
>	grey	# Grinnel to B/W display
>	lop "your operation here" < foo.pict | histeq | put "params"
>
>The point of all this is that reuse of code itself is unnecessary
>if the code is in a separate program.  All you need do insert the
>program at the appropriate point in the pipe.
>

I think this is an excellent example of the proper use of the Unix
design philosophy, and re-inforces my above comment that in an R&D
environment one often wants to "re-pipe" the plumbing.  In the graphics
world image processing applications lend themselves well to this approach
because one is applying succesive operators to an image.

Where often this falls down in a production situation, is that the overhead
involved in the successive pipes can often exceed the processing time
required for doing the "real" work.

>Now, if you are talking about applying the same operation to thousands
>of pictures a day, then (and *only* then) you should consider taking
>the `guts' of each operation out of each of the programs in question,
>building argument and error handling around them, and packaging that
>up as an `application'.

Precisely my point.  What you seem to be missing, is that the time and
effort involved in doing this packaging for production software often
is several times greater than that required "each operation".