October 14, 1997

Of Components and Analogies

On "components": Run-time instances, to me, are the correct analogues for physical "components."

If this is the case, then shouldn't the call against prefab components be a call for prototype-based programming? Languages like Self where each instance is separately tailorable? Or, should this comparison between architecture and software make us suspicious of interdisciplinary comparisons in general?

Analogies, architectural or linguistic or otherwise, are helpful, but only up to a point. When used properly, they lend support and familiarity to our descriptions of our arcane, ephemeral coalitions and constellations of bits. If you push any of them too far, you can break them. It's easy to get sucked into the analogies, particularly since all we really have are puddles of ones and zeroes at the bottom. Yet, good analogies, and good names, make it possible to talk about what we build. A dataflow application built around reusable streaming components may remind us of the Pompidou Museum, as its form emerges from around those elements. As with a well-engineered locomotive, our assessment of its QWANness may revolve as much around how well it does its job, as the does around the aesthetics or craftsmanship of either the program that engenders it, or the process and objects that emerge when it is run.

For many kinds of programs, analogies like chefs following recipes, troops following orders, orchestras following scores, or troupes of actors following scripts all reflect the dynamic nature of the program/process relationship better that our building analogies. Indeed, Von Neumann's brother claims he got the idea for the stored-program computer from reading Bach's the Art of the Fugue. Might our cult embrace Paul Prudhome, Sun-Tzu, Bach, or the Bard as it has Alexander?

Posted by foote at October 14, 1997 07:39 PM