Classification, Simplification
“To me, object-oriented programmers are like those victorian gentlemen scientists who used to go around the world, and try to classify butterflies into these incredible hierarchies…that’s kind of the way OO is –we try to think of things in terms of hierarchies.” –DAVE THOMAS
I agree with Dave, but I’d like to hone this observation a bit and say that, as programmers, when we abandon the pursuit of modelling heirarchies, it is not because there are no signatures of heirarchy in the world, but rather because heirarchies are riotously abundant, and they interact wildly. Heirarchies overlay each other, they interleave, they branch, they merge. The complexity of the interactions is so great, that attempting to model them is futile. It would be like attempting to create a video game which models a 3d world by first modelling each sub-atomic particle under the influence of the four fundemental forces. In the world of programming, with the models we create, we find power and utility by skipping over some details, and building a model which we know is deficient in many, many respects, but which nonetheless is helpful in some limited but important sense.
Heirarchies, as we now realize, did not turn out to be the programmer’s equivelent to the Grand Unification Theory. They are an example of a simplification which, when consistently applied, results in more complexity, not less. There are other examples of simplifications like this. Node.js, for instance, provides a beautiful simplification in the form of callbacks, but a straightforward, robust application of this concept tends to create code which is difficult to understand and mutate.
This suggests (to me, at least) a general principle which we might express this way: “Useful simplifications which provide great power in localized contexts tend to obfuscate a corresponding complexity when applied to wider contexts.” If this principle is true, then we can safely assume that it dogs our steps nearly everywhere we turn, especially in areas which are heavily influenced by computational models. It means that the insights gained from software-enabled analysis are also blinkers, in much the same sense that the scientist who gazes into a microscope is less aware of the lab around him.
We might point out that in the same talk referenced above, Dave posits another useful simplification, that all programming is fundementally data transformation. Won’t this simplification tend to create complexity elsewhere, in some broader context? Perhaps, but it’s worthwhile to observe that while the goal of the hierarchist is to provide a simplification for describing everything, Mr. Thomas’ simplification is targeted to a much narrower context, namely the context of computer programming. It is a more modest statement, more lightly burdened, and thus more likely to hold up.
