KludgeCode

is Ben Rudgers

Remarks: Epigram 9

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

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

Data structures are the characters within the story told by the program. Functions are the events those characters encounter. Have a protagonist. Make events relevant to the protagonist.

One data structure is chosen over another for efficiency. But the efficiency of a data structure is not intrinsic. It is a function of the methods used upon it balanced with the role of each method within the critical path of the program. Introducing a new data structure for the sake of speed can only make sense if the data structure and function combination is used in the critical path and the critical path is driven by performance considerations.

Tolkein wrote himself into a corner when he placed his protagonist at Mount Doom with no ring and a long way from home. But he didn’t restructure his story. He bashed the tale in place using:

    hobbit.eagles(characters)

It’s not beautiful enough to please a literary critic, but it works well enough for n epic. It’s a good example of reuse. Even if another journey across the plain of Mordor would make more logical sense, who’d want to read about that?

The tuple is the protagonist of LAMP and other software stacks. 100 or 1,000 query functions may be handled with aplomb. A program may let the user create arbitrary queries without undue concern. Even placing CRUD in the user’s hands is not out of the question – there is only a single set of safety protocols which need to be implemented.

If a second data structure is added, however, we must implement the protocols again. If a third data structure is added…etc.

So for expediency, the most likely outcome of multiple data structures is removing or limiting the power given to the user. The second most likely option is to provide different degrees of access depending on the level of effort put into programming the methods for user access. This is a source of frustration when the user legitemately anticipates a uniform level of power but is thwarted by a difference in access arising solely because of differences in data structure.

This was my experience with The Argument Button. An architectural decision created opacity where transparency was anticipated.  Like LAMP start with a single persistent data structure. Nobody cares what you do behind the scenes temporarily, but multiple persistent data structures create opacity or foster limiting the user’s power.