Unix/C program modularity

Kurt Papke papke at dicomed.UUCP
Wed Oct 16 11:54:10 AEST 1985


As a manager of programmers and engineers for 5 years and a practicioner
previous to that, I have noticed a disconcerting problem that tends to arise
in software systems designed under the Unix family of operating systems.
Since the vast majority of this software is written in C, this article is
being posted to Net.lang.c (if you feel this newsgroup is inappropriate,
tell me where to go :-))

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.

My observations are based on inspection of graphics applications (which
Dicomed is in the business of producing) which tend to be predominantly
user-interface stuff.  I am specificly NOT commenting on code used to
support program development, operating systems, and tools, but rather
applications programs that are used in a graphics production environment.

Why might this be the case ??  Further inspection of much code shows that
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!)

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.

	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.

	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.

	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.

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

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

(Speaker steps off soapbox amid a torrent of rotting vegetables)

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.  I
welcome counter-examples that would prove me merely mistaken.

	Kurt



More information about the Comp.lang.c mailing list