Unix/C program modularity

[Neal Ziring]

In article <637 at dicomed.UUCP> papke at dicomed.UUCP (Kurt Papke) writes:
> .. I have noticed a disconcerting problem that tends to arise
>in software systems designed under the Unix family of operating systems.
>
>The problem I have observed is that:
>
>	Applications programs that have been designed to run under Unix
>	tend to have a low percentage of re-usable code.

	Even just within a University environment, I have noticed that, too.
However, I don't know if that low percentage is being view in perspective,
and what the low percentage is relative to.

>My observations are based on inspection of graphics applications 
>
>Why might this [low percentage ] be the case ??  Further inspection
>[of code] 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!)

	Yes, and the fact that Unix provides the elegant and powerful
functionality of pipes, redirection, and signals is a great aid to 
developing powerful software quickly.  But, having powerful toys to
play with does not encourage discipline (like programming in assembler 
on a PDP-11 :-)

>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.

	I would rather see non-portable argument-parsing code than
lose the ability to read command-line arguments.  However, there
are argument parsing library routines on some version of Unix.  If
a programmer re-invents the wheel just to kill time, or because he
doesn't want to read the manual...

>	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.
>

	Alas, too true!  This can be alleviated somewhat by having
the parent program monitor things carefully, but recovery would probably
still be expensive.  The solution, in such cases, it to try to have
the filter fail soft (revert to `cat') or perhaps send a tell-tale
signal to it's entire process.  I am waiting for the Ach (shell with an
Ada-like syntax :-) so I can use Exception Handling in my shell scripts.

>	o Programs do not tend to be organized around a package concept,
>	  such as one sees in Ada or Modula-2 programs.  The programs are
>	  small, so data abstraction and hiding seem inappropriate.  Also
>	  the C language support for these concepts is cumbersome, forcing
>	  the programmer to use clumsy mechanisms such as ".h" files and
>	  "static" variables to accomplish packaging tasks.

	Poor organization like that is just plain laziness.  In a 
large applications effort, I think, object libraries should be used
extensively.  I admit that C has no support for data abstraction and
hiding; I wish it did!  You can still set up package-like libraries
without those facilties though -- "static" variables are useful for this.

>	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 because the programmer implemented
>	  a primitive system to satisfy the needs of this one filter.

	Laziness again.  The lack of standard high-level I/O facilities
is an invitation to the user to make up facilities that are no more complex
than he needs :-)  For serious applications, there are very good database
products available.  If a programmer is about to implement some standard
data structure (e.g. B-trees) he should consult with his fellows, and
see if they could use it, too!

>Despite all this, the graphics community is settling in on using Unix as
>the operating system of choice.

	Hooray!!

>Are we being lulled into using an O/S and language that allows us to whip
>together quicky demos to demonstrate concepts, at the expense of long-term
>usefulness as a finished product ??

	I don't think so.  Sure, Unix and C have problems.  The have LOTS
of nice aspects too, and many of the problems are shared by other systems
and language.  For instance, try to do data abstraction in Fortran.   Ada
promises to provide all the lovely Computer Science concepts that we all
would like (packaging, object-orientation, parallelism) but so far those
services are not widely available in commercially viable language systems.
Ada has problems, too, but I'll save discussion of them for net.lang.ada.

>My secondary intent here is to try to stimulate discussions in this newsgroup
>that rise above disputes as to how far to indent your curly braces.  

	Good idea.  Any other comments from the net about the points
raised here, and in Mr. Papke's original article?
-- 
========
...nz (ECL - we're here to provide superior computing)
	Washington University Engineering Computer Laboratory

    "Now we'll see some proper action..." 

	old style:	... ihnp4!wucs!nz
	new style:	nz at wucs.UUCP