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: laura@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: laura@l5.UUCP (Laura Creighton) Organization: Ell-Five [Consultants], San Francisco Lines: 138 In article <637@dicomed.UUCP> papke@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) . 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!laura@lll-crg.arpa