Path: utzoo!mnetor!uunet!lll-winken!lll-tis!mordor!lll-lcc!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.software-eng Subject: Re: Cynic's Guide to Software Engineering, part 3 Message-ID: <5879@well.UUCP> Date: 4 May 88 21:46:31 GMT References: <5752@well.UUCP> <985@nuchat.UUCP> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Distribution: na Organization: The Blue Planet Lines: 132 In a previous article, Steve Nuchia responds to my response to his previous article ... > >From article <5752@well.UUCP>, by shf@well.UUCP: > > I wrote a couple of image processing programs in Pascal once. I was ... > People who profess a preference for one kind of language over > others usually approach problems from a perspective appropriate > to that kind of language. ... ... > I'm not trying to say that Mr. Ferguson is wrong, I'm generalizing. > But I do find his argument unconvincing - it amounts to proof > that he likes to program in FORTRAN by reasoning circularly from > the premise that he likes to program in FORTRAN. I undoubtedly made a mistake in phrasing my article the way I did. It's easy to take what I said as material for a language war, but that was not at all my intention. Let me re-iterate: >> ... I'm not pushing >> Fortran as some kind of True and Great language, but I AM suggesting >> that the source of some of the problems Steve addresses may be a result >> of more than JUST the choice of programming language. Language wars start with the premise that the Quest is to find the Right Language. Although there are always language choice issues involved in software engineering, the ultimate goal has always really been to write Good Programs. In one's personal Quest for Good programs, one may find that some programming paradigms can provide greater insight and freedom than others. I wrote in an apparant defense of Fortran partly because it's one of those languages that programmers snicker about even though they themselves have never written a line of Fortran code. (Rather like COBOL in that respect -- or lack of it :-).) But the real issue is not about any particular language, it's about producing good code, and on that front I agree pretty well with what Steve has said. He summed it up much more eloquently than I: >A skilled and disciplined programmer can produce high quality >programs in any language. No language can prevent poor code. On the real issue: >> The "scientific" programs which start small and grow, such as the ones >> that Steve refers to, are rarely planned. Rather they evolve out of the >> kind of interactive development (i.e. hacking) that I described. For >Excelent points. My point in relation to the unplanned growth >was simply that at some point the program gets so large, and >is doing so many unexpected things, that the original language >choice is no longer appropriate. Common practice does not have >a provision for recognizing and dealing with that threshold; I >am proposing that making such a provision explicitly would be >a good thing. Secondarily I'm arguing that having that mechanism >in place would reduce a lot of the motivation for the language wars. The motivation for this is excellent. Mr. Nuchia has made an observation (that I can verify to some extent) that small programs often grow into big programs and the original language in which they were formulated is no longer appropriate to the kind of program it has become. The original language Steve refers to is Fortran, but it could just as easily be BASIC, Lisp, LOGO or Ada for that matter. In alot of cases, there may be a point where it would make sense to use a different programming language in order to facilitate writing good code. The problem then becomes one of recognizing and dealing with this threshold, rather than one of struggling with an innapropriate language. [discussion of "Nuchia's Law" and the meaning of a "production" program] >By production program I mean one that has a user's manual, dozens >of users at several site, and is run orders of magnitude more often >than it is compiled. Obviously this isn't a definition of the term, >but you get the idea. I do. You mean a "production" program in the sense that the program is the _product_, not in the sense that the program is _used_ for production. We have a lot of programs we use as part of a data production pipeline which get run orders of magnitude more than they get compiled, but we do not have programs which are a product in themselves. [discussion of libraries] >Once again we are seeing things differently because we are looking >at different things. ... >... What >I had in mind were things like the Macintosh Toolkit or Suntools >or similar graphical interactive user interface environments. Even >the typical spreadsheet or data entry screen needs significantly more >sophistication than your prompter can give, and that additional complexity >inevitably impacts the design of your code. I was again not trying to push the prompt library as a great thing in and of itself. I'm sure nobody's interested in that, especially not in comp.software-eng. I was trying to illustrate my point that many libraries are not well designed. The issues of library interface and user interface are strongly analogous, and lessons learned in one are often applicable to the other. The sophistication and sheer complexity of graphical user interfaces means that all that much more time should be spent designing a proper programmer interface. Sometimes with domains as complex as this one it makes sense to go beyond the conventional idea of just compiling a library of useful functions. When the task represents a whole formal domain in itself, it can make sense to provide design tools which address the formal domain directly. Databases are a good example. Databases can be implemented as a library interface to a general-purpose programming language, but since database management is such a large and well-defined domain in itself it can be worthwhile to write database languages -- DBaseII, for example -- which are a kind of special-prupose programming language giving more direct access to the formalisms of database management. If you do this, the trick then becomes interfacing the special-purpose language to other languages in order to implement the things not easily accessable by the formalisms of the special-purpose language. This is exactly the issue Nuchia is addressing when he refers to the "threshold," the point where it makes sense to shift language rather than muddle through using an innapropriate formal domain. >The remainder of Mr. Ferguson's article contains very good data >on his experiences with growing programs, exactly the kind of >information I had asked for. Thank you! >Steve Nuchia | [...] but the machine would probably be allowed no mercy. You're welcome. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)