Making the case for repeat

[Steven D'Aprano]

Boris Borcic wrote:

> 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.

This is much the same that happens in maximisation problems: the value gets
trapped in a local maximum, and the only way to reach a greater global
maximum is to go downhill for a while.

I believe that hill-climbing algorithms allow some downhill movement for
just that reason. Genetic algorithms allow "mutations" -- and of course
real evolution of actual genes also have mutation.


-- 
Steven