This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Programs are texts
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
...and, perhaps, more texts are programs than we realize.
One of the reasons software development is hard to do, and harder still to manage, is that there's no accepted wisdom as to exactly what software development is. The nature of the beast is still largely a mystery.
Some have argued that developing software is akin to drafting a prose document - anything from articles to chapters to books and beyond, depending on the discussion. As analogies go, it's a rich and fruitful one in the way good analogies are - it prompts you to consider many alternatives to established wisdom that you may not normally consider.
For instance, authors of successful novels vary wildly in how they design book-length texts: some prefer to work from a detailed outline, that becomes ever more detailed until eventually it has been fleshed out into a book; others prefer to write bits of the story as they occur to them and over time glue the bits together into a book, rewriting large portions as they go along; others still just sit at the typewriter (or PC), start out hammering a beginning and bang away until they come to the ending. This may hold suggestions as to the necessity of always starting a development effort with a detailed schedule, or a detailed design.
There is also a common objection to the analogy, which goes like this: programs are only valuable if they work, and there is no sense in which texts "work" like programs "work" - deterministic, predictable, repeatable. People like a text, or don't like it. They understand it, or they don't - writers try their best, but they can't tell if they'll be understood.
I suspect that the objection betrays a narrow response to the term "text". The objection carries some weight when we are thinking primarily of "literary" texts, where the "work" to be done is emotional; novels, poems, etc. That sense of "works" is very distant from what we mean when we say a program "works".
But in fact there are many more kinds of texts which have to "work" in ways that are much closer to the way programs must "work". Not exactly the way that programs "work" - but the differences are small enough that we may learn something from the comparison.
For instance:
Poems (before we leave the literary world entirely) have to obey certain formal constraints, such as rhyme, meter or stanza structure. In fact you could conceive of a program to check these properties automatically. A violation of those constraints would be a "bug" in a sense closer to the one we use - a syntax error.
Mathematical proofs: these provide a good "intermediate" stage between ordinary prose and computer programs, in a conceptual but also historical and sociological sense. A proof may be extremely formal (to the point that it could be checked by a program), or it may be breezily informal ("imagine the triangle flipped and superposed over the non-flipped version"), but the slightest misstep will cause it to "fail" in important ways.
Scientific theories: it is usually not possible to fully express those in mathematical formalisms, so they represent a distinct category; although some (e.g. particle physics) rely on extensive mathematics, they also contain elements, such as their ontologies ("what objects exist in the theory") which cannot be formalized. In one view, a theory "works" if it predicts observable events in the world, and scientific progress consists of eradicating "bugs" (events not predicted, or events predicted which are not observed).
Contracts: a loophole is to a contract as a bug is to a program. These are texts which have to "work" in an even closer sense to the way programs must "work". Authors of contracts cannot rely on a sympathetic reader to fill in the blanks for comprehension; rather, they assume that their creations will be scrutinized with, at best, indifference to their aims, and at worst active hostility. Contracts will be interpreted as literally as necessary *and* as liberally as necessary to defend the attackers' conclusions.
Systems of laws, game rules, etc: these can be considered as generalizations of the idea of "contract" to multiple parties, or specializations of it to various domains. These texts can be considered to "work" or "fail" in more diverse ways than contracts. A game "fails" if it is impossible to play, of course. For a game to "work", its rules must also be simple while generating non-trivial strategies.Games "fail" if it is too obvious how to win, or impossible to win.
Laws in particular are interesting because one could say that they "program" a society, that they are the "software" which runs on the "hardware" of that society's infrastructure. Just as with computers, that software has a wide range of variablity, subject to constraints related to physical law and regularities of human nature. Just as with computers, there are common, best-practice "architectures" such as representative parliamentary democracy.
Given all this, it's unlikely that the programming profession can learn nothing from attentively studying the techniques practiced by the literary or more broadly the "text-oriented" disciplines, when these disciplines succesfully attack problems no less complex than the ones we are presented with.
Previous Topic
