Xref: utzoo comp.misc:8501 comp.sys.ibm.pc:46627
Path: utzoo!attcan!uunet!deimos.cis.ksu.edu!ux1.cso.uiuc.edu!uwm.edu!uwvax!rang
From: rang@cs.wisc.edu (Anton Rang)
Newsgroups: comp.misc,comp.sys.ibm.pc
Subject: Re: The *ART* of Computer Programming
Message-ID: <RANG.90Mar17125101@derby.cs.wisc.edu>
Date: 17 Mar 90 18:51:01 GMT
References: <1990Mar3.065257.13674@wolves.uucp> <14203@cbnewsc.ATT.COM>
	<2308@bnr-rsc.UUCP> <25fed2fe.1f3e@polyslo.CalPoly.EDU>
Sender: news@spool.cs.wisc.edu
Followup-To: comp.misc
Organization: UW-Madison CS department
Lines: 43
In-reply-to: jdudeck@polyslo.CalPoly.EDU's message of 14 Mar 90 23:25:50 GMT

In article <25fed2fe.1f3e@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
>In article <2308@bnr-rsc.UUCP> bnr-rsc!bcarh186!maclean () writes:
>>If the code is extremely convoluted then it is entirely likely that the
>>programmer was not creative enough.  Creativity is a must for creating
>>good, maintainable code.
>
>I agree heartily.  Convoluted code is *never* the best solution to any 
>programming problem.

  I think someone pointed out earlier that there are times when
convoluted code is necessary to satisfy some constraints of the
problem.  Especially when working on microcomputers, these seem to pop
up once a year or so in the stuff I do.

  If you have an interrupt handler with a critical time constraint,
for instance, you may have to put some real convolutions into the code
to get it to run quickly enough.  (This involves a lot of creativity,
too--just a different kind.)  Another example is working with a
program with 150K of free memory and 2 MB of data, when some
operations scan every record, but only a particular field--it's
convoluted to maintain an array in memory which parallels part of the
records stored on disk, but it may mean the difference between a
program which is too slow to use and one which is workable.

>Maintaining "creative" code takes the creativity that the one who
>wrote it didn't have in the first place.

  If it's properly documented, it's not necessarily too bad.  I try to
avoid convolution, and when I'm writing a program I try to do it the
most straightforward way.  If I find something which forces me into
doing convolution, I'll keep the (unconvoluted) algorithm in the docs,
along with an explanation of what "tricks" have been used, and why.
I've gone back to programs like this I've written, 7 or 8 years later,
and (after perusing the documentation for a few minutes) it's not hard
to change them.

  Just my $.02....

	Anton
   
+---------------------------+------------------+-------------+
| Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison |
+---------------------------+------------------+-------------+