Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site dicomed.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!dicomed!papke
From: pa...@dicomed.UUCP (Kurt Papke)
Newsgroups: net.lang.c
Subject: Unix/C program modularity
Message-ID: <637@dicomed.UUCP>
Date: Tue, 15-Oct-85 21:54:10 EDT
Article-I.D.: dicomed.637
Posted: Tue Oct 15 21:54:10 1985
Date-Received: Thu, 17-Oct-85 02:21:33 EDT
Organization: DICOMED Corp., Minneapolis
Lines: 59
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: Unix/C program modularity
Message-ID: <2903@sun.uucp>
Date: Thu, 17-Oct-85 05:31:47 EDT
Article-I.D.: sun.2903
Posted: Thu Oct 17 05:31:47 1985
Date-Received: Sat, 19-Oct-85 05:43:45 EDT
References: <637@dicomed.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 10
> 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 ??
Nothing in UNIX or C *forces* you to write applications in the style you
describe. It is not appropriate to write every application under the sun as
a collection of filters, and lots of excellent applications running under
UNIX are not so written.
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!
talcott!harvard!seismo!brl-tgr!gwyn
From: g...@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re: Unix/C program modularity
Message-ID: <2220@brl-tgr.ARPA>
Date: Thu, 17-Oct-85 13:05:46 EDT
Article-I.D.: brl-tgr.2220
Posted: Thu Oct 17 13:05:46 1985
Date-Received: Sat, 19-Oct-85 03:59:14 EDT
References: <637@dicomed.UUCP>
Organization: Ballistic Research Lab
Lines: 78
> 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.
UNIX code comes in several flavors. I am not familiar with Dicomed's
software design and coding practice. Maybe it's just not very good?
> 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!)
Exactly! Re-usability is obtained at the higher, process, level.
Many new applications should be produced by combining existing tools
rather than by writing code in the traditional sense. This works
especially well when one is trying to support a wide and growing
variety of graphic devices.
> 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.
The shell is eminently reusable. Within each process, argument
processing should be done via getopt(), in the standard library.
Beyond that, obviously different processes are going to have
different specific requirements.
> 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.
If a subordinate module is not able to perform its assigned task,
it should so indicate to its controlling module. Error recovery
is best performed at the higher strategic levels. UNIX processes
indeed do have a simple means of returning error status to their
parents.
> 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.
There is no need to emulate Ada packages, if module interfaces are
clean and well-defined. The UNIX process interface usually is.
Within processes, the facilities C provides are generally adequate,
although some prefer to spiffy up intra-process module design via
"classes", "Objective-C", "C++", or some other preprocessing scheme.
We have not felt much need for this in our UNIX graphics work.
> 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.
It is relatively rare that UNIX applications have to be concerned
with detailed file access mechanisms. There is as yet no standard
UNIX DBMS, so portable UNIX applications have to either work without
one or provide their own. Most graphics applications do not need the
complexity of a DBMS, but can work with simple data formats.
> Despite all this, the graphics community is settling in on using Unix as
> the operating system of choice.
That's because it supports rapid development of good, flexible systems
that can be ported widely with little additional expense.
> 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 ??
You should make your own decisions.
Do you have a better approach to suggest?
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!
seismo!lll-crg!well!l5!laura
From: la...@l5.uucp (Laura Creighton)
Newsgroups: net.lang.c
Subject: Re: Unix/C program modularity
Message-ID: <197@l5.uucp>
Date: Thu, 17-Oct-85 15:01:31 EDT
Article-I.D.: l5.197
Posted: Thu Oct 17 15:01:31 1985
Date-Received: Sat, 19-Oct-85 07:21:32 EDT
References: <637@dicomed.UUCP>
Reply-To: la...@l5.UUCP (Laura Creighton)
Organization: Ell-Five [Consultants], San Francisco
Lines: 138
In article <6...@dicomed.UUCP> pa...@dicomed.UUCP (Kurt Papke) writes:
>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.
>
>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!)
Boy! Maybe I should go work for you. The applications that I see the most
are these huge megaliths which reivent the wheel all the way down the line.
There is a body of people who think that the best sort of application program
is one that does everything. As a result you see programs which show the
strain marks as everything including the kitchen sync was jammed in to fit.
People who are working on fairly hostile O/S's like MS/DOS may be absolutely
correct in this perception for their environment, but every time I find a
unix application program that reimplements strcpy **AGAIN** or atoi or
any number of other things...but I digress.
>
>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 think that you have missed out on the unix design philosophy here. There
is nothing sacred in filters, per se. A good filter does one job well. If
people are rewriting the argument parsing for every new application, rather
than reusing exiting argument parsing, then either argument parsing cannot
be done by a standard filter, or you have not written the filter you need
yet. For a long time *all* unix programs did their own argument parsing.
Now we have getopt(3) <and some earlier programs which cannot be conveniently
converted to use getopt, alas>. Getopt solves the parsing problem -- noone
need ever write an argument parser for a standard unix program again.
If your application programs are such that it is possible that one general
parser could parse all or most of them, then you should write that and then
you will have the reusable code that you want. If your applications are
not structures this way and cannot be restructureshd this way, then you
will have to write an argument parser for each application. But I fail to see
that you are going to avoid this problem if you write it in any other style -
it seems inherant in the nature of such applications.
> 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 *wrong* *wrong* *wrong*. Most unix programs do not check for errors,
this is true. But this is because the programmers are either sloppy, or do
not know how to check for errors. See *Real Programs Dump Core* by Ian Darwin
and Geoff Collyer. I think that this paper was in the winter 84 usenix, but
if I am wrong I am sure that they will both post corrections....
Most unix programs filters do not break at the pipes. They break because
you run out of file descriptors, or because malloc fails, or because you
cannot open a file for some reason, or because you try to divide by zero.
All of these things can be, and should be checked. There is nothing in the
unix philosophy which says that you have to be sloppy or lazy about this.
[More and more I am coming to the conclusion that the problem is not sloppiness
or laziness, just sheer ignorance, by the way. Do the world a favour. Teach a
friend to check the return codes of system calls. Then teach him to use lint.]
>
> 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.
This is a real deficiency. However, if you write your filters correctly, you
can view them as packages and treat them the same way. I have never used any
language which has modules for any serious work, but I have often wondered how
useful they actually are. There are nights when I think that data abstraction
is a virtue because ``real programmers won't use lint'' and its chief virtue is
that it handles your casts for you. Some modula-2 enthusiasts have agreed with
me about this, and I will probably get a lot of rotten tomatoes from the rest.
But I still don't know how to measure how useful classes and the like are. I
don't know how to meausre why I like programming in lisp more than programming
in C either, though.
>
> 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.
What you need to do is to select your standard and then write the rest of
your code to deal with it. This is not a problem with the unix philosophy, but
a problem because you have not set a standard and required your code use it.
>
>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 ??
It depends on how you run your company, of course. If you do not have
re-usable code then I think that you need to identify what you are rewriting
and then make a standard and comply with it. If you can't get re-usable
code with unix then I can't see why you expect to get it anywhere else...the
mechanisms seem the same to me. I may be missing something, but I can't see
what.
In addition there are a fair number of exisiting unix graphics standards in
existence. Couldn't you standardise around one of them?
>
>(Speaker steps off soapbox amid a torrent of rotting vegetables)
>
Well, i don't thinkt hat I was that bad, was I?
--
Laura Creighton
sun!l5!laura (that is ell-five, not fifteen)
l5!la...@lll-crg.arpa
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utcs.uucp
Path: utzoo!utcs!geoff
From: ge...@utcs.uucp (Geoff Collyer)
Newsgroups: net.lang.c
Subject: Re: Unix/C program modularity
Message-ID: <930@utcs.uucp>
Date: Sat, 19-Oct-85 17:15:08 EDT
Article-I.D.: utcs.930
Posted: Sat Oct 19 17:15:08 1985
Date-Received: Sat, 19-Oct-85 18:15:36 EDT
References: <637@dicomed.UUCP> <197@l5.uucp>
Reply-To: ge...@utcs.uucp (Geoff Collyer)
Organization: University of Toronto - General Purpose UNIX
Lines: 8
Summary: Real Programs Dump Core is in Winter *85* Usenix proceedings
In article <1...@l5.uucp> la...@l5.uucp (Laura Creighton) writes:
>See *Real Programs Dump Core* by Ian Darwin
>and Geoff Collyer. I think that this paper was in the winter 84 usenix, but
>if I am wrong I am sure that they will both post corrections....
"Can't Happen or /* NOTREACHED */ or Real Programs Dump Core" appears in
the proceedings of the Dallas (January 1985) Usenix conference.
Ian gave the talk and I'm told it was much funnier than the paper.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site sdcc7.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!
decvax!ittatc!dcdwest!sdcsvax!sdcc3!sdcc7!ln63fkn
From: ln63...@sdcc7.UUCP (Paul van de Graaf)
Newsgroups: net.lang.c
Subject: Re: Unix/C program modularity
Message-ID: <133@sdcc7.UUCP>
Date: Mon, 21-Oct-85 05:19:12 EDT
Article-I.D.: sdcc7.133
Posted: Mon Oct 21 05:19:12 1985
Date-Received: Wed, 23-Oct-85 05:58:31 EDT
References: <637@dicomed.UUCP> <1219@wucs.UUCP>
Reply-To: ln63...@sdcc7.UUCP (Paul van de Graaf)
Organization: U.C. San Diego, Academic Computer Center
Lines: 25
The problem here is not a question of programmers forever reinventing the wheel,
but rather a lack of uniformity of the various flavors of Unix. Most defensive
programmers take into account that the programs they write might be ported to
v6 or XENIX or even a micro that only has an incomplete implementation of the
stdio package (if that much). Writing a program with a myriad of fancy pipes
and filters may be faster and easier, but if you don't want to go the extra
mile to write emulations of certain system calls and a lot of ugly #ifdefs,
you're going to lose if you try to port.
The GNU project, the ANSI C standardization commitee, and the /usr/group people
are all working on this problem from different directions, so don't expect an
answer too soon. The GNU effort has great promise, because it could act as a
clearinghouse for all those system-call emulators. Whether this fits in with
their plans, I can't say, but I'd love to be able to call them up and get the
102nd version of getopt() for my Hal 9000 for a nominal charge. I kind of feel
the ANSI C people decided that it was boring to standardize C, so they spilled
over into Unix interface standardization. C and Unix aren't always synonymous,
especially on micros: witness the Amiga and the Atari ST. If they don't stay
on track, they may jeapordize their whole standard. The /usr/group folks talk
a lot, but nobody listens... they're JUST a user group anyway :-)!
Tough decisions need to be made in order to come up with a standard.
In the meanwhile, I'm coding defensively.
Paul van de Graaf sdcsvax!sdcc7!ln63fkn U. C. San Diego
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site dicomed.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!dicomed!papke
From: pa...@dicomed.UUCP (Kurt Papke)
Newsgroups: net.lang.c
Subject: Re: Unix/C program modularity
Message-ID: <641@dicomed.UUCP>
Date: Tue, 22-Oct-85 21:38:56 EDT
Article-I.D.: dicomed.641
Posted: Tue Oct 22 21:38:56 1985
Date-Received: Fri, 25-Oct-85 02:03:18 EDT
References: <637@dicomed.UUCP> <1898@umcp-cs.UUCP>
Reply-To: pa...@dicomed.UUCP (Kurt Papke)
Organization: DICOMED Corp., Minneapolis
Lines: 80
Summary:
In article <1...@umcp-cs.UUCP> ch...@umcp-cs.UUCP (Chris Torek) writes:
>[This is in response to article <6...@dicomed.UUCP> by
>pa...@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".
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!decwrl!sun!guy
From: g...@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: Unix/C program modularity
Message-ID: <2933@sun.uucp>
Date: Sat, 26-Oct-85 18:10:07 EST
Article-I.D.: sun.2933
Posted: Sat Oct 26 18:10:07 1985
Date-Received: Mon, 28-Oct-85 04:17:04 EST
References: <637@dicomed.UUCP> <1219@wucs.UUCP> <133@sdcc7.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 59
> The problem here is not a question of programmers forever reinventing the
> wheel, but rather a lack of uniformity of the various flavors of Unix.
> Most defensive programmers take into account that the programs they write
> might be ported to v6 or XENIX or even a micro that only has an incomplete
> implementation of the stdio package (if that much).
If you're talking about a micro with only an incomplete standard I/O
implementation, you're talking about the lack of uniformity of various C
implementations, not of various flavors of UNIX. Every UNIX since V7 has
had a standard I/O library, although there are some differences between
them. The original V6 didn't, but V6 without the "50 changes" and
"Phototypesetter, Version 7" is sufficiently different from all subsequent
UNIXes that trying to write code that builds under it and other systems is
extremely difficult.
> Writing a program with a myriad of fancy pipes and filters may be faster
> and easier, but if you don't want to go the extra mile to write emulations
> of certain system calls...
Again, if you're talking about "standard" UNIX system calls, you're dealing
with the problem of porting between different operating systems. I know of
few languages at the approximate level of C which permit you to
transparently port applications which run as screen editors, or which run
other programs, or.... The whole reason the people at Bell Labs ported UNIX
was to get around the problem of dealing with multiple machine architectures
*and* operating systems:
The realization that the operating systems of the target
machines were as great an obstacle to portability as their
hardware architecture led us to a seemlingly radical suggestion:
to evade that part of the problem altogether by moving the
operating system itself. (S. C. Johnson and D. M. Ritchie,
"Portability of C Programs and the UNIX System", BSTJ Vol. 57,
No. 6, Part 2, July-August 1978, pp. 2021-2048)
At that time, both machines (PDP-11 and Interdata 8/32) were (I presume)
running V7. Since then, several cooks (the UNIX Support Group/UNIX System
Development Laboratory, U. C. Berkeley's Computer Science Research Group,
10000 other universities, Microsoft, 10000 other UNIX vendors, etc., etc.)
have made their contributions to the broth. I hear that lots of
applications broke when moving from VMS 3.x to VMS 4.x also...
> C and Unix aren't always synonymous, especially on micros: witness the
> Amiga and the Atari ST. If they (the ANSI C standards committee) don't
> stay on track, they may jeapordize their whole standard.
Amen. The trouble is that C has, for example, no built-in I/O constructs,
so the original UNIX C implementation had an I/O library. A portable
version was written (two, actually - the Portable I/O library and its
replacement, the Standard I/O library), but it still had a UNIX flavor to
it. The ANSI C committee is doing some really dumb things like building the
signal mechanism into their standard. Anybody who wants to write an
application in *any* language which they want to run under, say, VMS and
UNIX, and which makes use of the operating system's facilities in ways that
can't be subsumed by the languages built-in I/O capabilities is going to
have to build an OS interface library and hide the OS dependencies there
anyway.
Guy Harris
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!
talcott!harvard!seismo!brl-tgr!tgr!cottr...@NBS-VMS.ARPA
From: cottr...@NBS-VMS.ARPA (COTTRELL, JAMES)
Newsgroups: net.lang.c
Subject: UNIX/C Program Modularity
Message-ID: <2527@brl-tgr.ARPA>
Date: Mon, 28-Oct-85 16:20:33 EST
Article-I.D.: brl-tgr.2527
Posted: Mon Oct 28 16:20:33 1985
Date-Received: Wed, 30-Oct-85 06:22:33 EST
Sender: n...@brl-tgr.ARPA
Lines: 13
/*
> 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.
Exactly! What this means is that you get to keep writing NEW stuff! The
common fragments have mostly been culled out and stuck into a library
for you. This is the mark of a successful design.
jim cottrell@nbs
*/
------
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: UNIX/C Program Modularity
Message-ID: <6098@utzoo.UUCP>
Date: Wed, 30-Oct-85 15:32:48 EST
Article-I.D.: utzoo.6098
Posted: Wed Oct 30 15:32:48 1985
Date-Received: Wed, 30-Oct-85 15:32:48 EST
References: <2527@brl-tgr.ARPA>
Organization: U of Toronto Zoology
Lines: 20
> > Applications programs that have been designed to run under Unix
> > tend to have a low percentage of re-usable code.
>
> Exactly! What this means is that you get to keep writing NEW stuff! The
> common fragments have mostly been culled out and stuck into a library
> for you. This is the mark of a successful design.
Actually, "mostly" is overstating the situation. As various people, notably
the Software Tools folks, have pointed out, it's so easy to do various
things in Unix that nobody gets around to making library routines out of
them -- it's too easy to reinvent the wheel each time. There ought to be
rather more use of libraries than there is. Things like getopt(3) and the
SysV string(3) routines are forward steps. (Note to listeners: both of
these examples exist in public-domain versions that have been posted to
the net repeatedly, so there is NO EXCUSE for not having them.) Some of
the functions in Kernighan&Pike are also good candidates for putting in
libraries.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry