Making the case for repeat

[Boris Borcic]

Raymond Hettinger wrote:
> There is a natural inclination to do the opposite.  We factor code
> to eliminate redundancy, but that is not always a good idea with
> an API.  The goal for code factoring is to minimize redundancy.
> The goal for API design is having simple parts that are easily
> learned and can be readily combined (i.e. the notion of an
> iterator algebra).

This reminds me of an early programming experience that left me with a 
fascination. At a time where code had to fit in a couple dozens kilobytes, I 
once had to make significant room in what was already very tight and terse code. 
Code factoring *did* provide the room in the end, but the fascinating part came 
before.

There was strictly no redundancy apparent at first, and finding a usable one 
involved contemplating code execution paths for hours until some degree of 
similarity was apparent between two code path families. And then, the 
fascinating part, was to progressively mutate both *away* from minimality of 
code, in order to enhance the similarity until it could be factored out.

I was impressed; in various ways. First; that the effort could be characterized 
quite mechanically and in a sense stupidly as finding a shortest equivalent 
program, while the subjective feeling was that the task exerted perceptive 
intelligence to the utmost. Second; by the notion that a global constraint of 
code minimization could map more locally to a constraint that drew code to 
expand. Third; that the process resulted in bottom-up construction of what's 
usually constructed top-down, mimicking the willful design of the latter case, 
eg. an API extension, as we might call it nowadays.

Cheers, BB
--
"hope achieves the square root of the impossible"