KludgeCode

is Ben Rudgers

Remarks: Epigram 2

This is part of a writing exercise around Alan Perlis‘s Epigrams in Programming.

Functions delay binding. Data structures induce binding. Moral: Structure data late in the programming process.

Maybe I know what it means, or rather I know the starting point for figuring out what it means to me right now. If I have the expression:

(setq y (foo x))

Then I have to wait for foo to do its work before I do the binding of its output to y. Furthermore, I can modify foo to get exactly what I want bound to y – I can get y just right – up until the moment foo returns.

So y could bind to an atom or a list or a structure or a hashtable depending on what is needed (and assuming no <type> safety is needed or imposed despite no need. Conversely, if I use something like:

(setq y (list :print poo :format foo :dependency doo))

I need to use a specific form (getf y :print) embedded in my program (or something which evaluates identically in order to do my printing [I am locked in to a specific implementation once I create the alist]. My program has become more brittle at this point in development – i.e. the point where I structured my data.

At some point of course, my data may need to be structured. But the structuring of my data is for the benefit of the user, not the programmer. Structuring data produces predictable behavior which benefits the user, and rigidity which is to the detriment of the program development process. [Although as a constraint it may be beneficial  from a program design standpoint].