Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site sjuvax.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!astrovax!sjuvax!jss From: jss@sjuvax.UUCP (J. Shapiro) Newsgroups: net.lang.c Subject: Re: Re: Unix/C program modularity Message-ID: <2426@sjuvax.UUCP> Date: Mon, 21-Oct-85 10:53:55 EDT Article-I.D.: sjuvax.2426 Posted: Mon Oct 21 10:53:55 1985 Date-Received: Wed, 23-Oct-85 05:00:24 EDT References: <637@dicomed.UUCP> <2220@brl-tgr.ARPA> Organization: Haverford College, Haverford, Pa. Lines: 123 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