Unix/C program modularity

[J. Shapiro]

Doug, I have yet (to my recollection) to disagree with you on
anything, but I think I finally do...

The following comments were edited (no applause - just send grant
applications)...

----cast of characters---
> Doug's Comments...
> > someone else, whose name did not appear in Doug's posting (sorry).
-------------------------

> > ...Applications designed for the Unix environment tend to follow the
> > spirit of the Unix operating system: design your system as a series
> > of small programs and "pipe" them together (revelationary!)
> 
> Re-usability is obtained at the higher, process, level.

Doug, you are entirely correct, but this does not negate the case in
favor of lower level reusability.  Go figure out one day how much of
your disk is being used by copies of the C library. Compile a program

	main(){}

using the "-lc" option and multiply this size by the number of
executable files on your system.  I think you will be astonished.
Having modularity at the procedure level can be a great boon,
particularly if you have a loader which links in libraries at run time
and doesn't duplicate code unnecessarily.

> Many new applications should be produced by combining existing tools
> rather than by writing code in the traditional sense.

I agree, in a development environment.  In an applications environment
this leads to systems which are inconsistent, have no reasonable error
messages, are poorly documented, and are confusing as hell in
general.  This is not an intrinsic property of the approach, except to
the extent that the approach does not enforce programmer discipline in
such matters.

> This works especially well when one is trying to support a wide and growing
> variety of graphic devices.

Again, a general purpose device independent graphics library would
probably serve the need better, and would almost certainly allow for
more efficient collapseing of common code used.  It would also narrow
the scope of modifications necessary to support new devices, thereby
helping to minimize support costs.

> > As a result of this philosophy to design systems as a network of filters
> > piped together:
> > 
> > 	o Much of the bulk of the code is involved in argument parsing,
> > 	  most of which is not re-usable.

If your argument parsing is so long, you haven't done it sensibly, or
your argument conventions need to be rethought.  No matter how you
slice the program, It has to take arguments, and the shell is doing
all of the argument division anyway, so there is no added complexity
to speak of involved in the use of pipes.

> > 	o Error handling is minimal at best.  When your only link to the
> > 	  outside world is a pipe, your only recourse when an error
> > 	  occurs is to break the pipe.

This is not really true.  I do agree, however, that error recovery is
substantially harder if your disjoint pieces of code are not properly
modularized.  If you and the next guy in the pipe sequence need to
resynchronize your notion of the data stream, you have invoked a lot
of code AND protocol overhead.  C's modularity and data sharing
facilities are not what they could be.  It is one of the only features
of Modula-2 which I like, though I think the Modula-2 approach is a
pain.

> If a subordinate module is not able to perform its assigned task,
> it should so indicate to its controlling module.

Have you ever tried to implement this using only error(n)?  Talk about
rendering your code complex...

> Error recovery is best performed at the higher strategic levels.

Depends on the kind of error.  This argument comes back to the
modularization point I made above.

> > 	o Programmers invent "homebrew" data access mechanisms to supplement
> > 	  the lack of a standard Unix ISAM or other file management.  Much
> > 	  of this code cannot be re-used...

I know of no database system where speed is important which has ever
been distributed using a standard record support library.  I believe
that you will find that all of the major database products, even under
VMS, ultimately have given up and gone directly to doing their own
thing directly using Block I/O because the provided record structure
facilities, by virtue of the fact that they are general, are
necessarily not well optomized to any particular task.  In particular,
the overhead associated with error checks which your database system
doesn't need is hideous.

On the other hand, a resaonable record structure facility is something
sorely lacking in UNIX, and is very useful when simply trying to get
the code running initially.  It allows you to leave the modifications
for a database hacker and get it running.  For non-critical code, or
code where the critical element is development time and ease of
support, this is crucial.

> It is relatively rare that UNIX applications have to be concerned
> with detailed file access mechanisms.

Is this cause, or effect?

I hope that my replies here are not unduly long.  I went over them,
and I believe that I have made my points succintly: UNIX needs both a
standard database facility and an intelligent notion of run-time
libraries.

Jon Shapiro
Haverford College
-- 
Jonathan S. Shapiro
Haverford College

	"It doesn't compile pseudo code... What do you expect for fifty
		dollars?" - M. Tiemann