Extreme TrackingTim Toady Bicarbonate
Ξ October 26th, 2009 | → 2 Comments | ∇ codework |
[by Stephen Ramsay]
It would be hard to imagine the computer revolution without acronyms. Back in the day, the mere fact that you manufactured computers meant that you could no longer be a corporation that made “digital equipment” — still less an international purveyor of “business machines.” Since then, we’ve been subjected to a seemingly endless stream of acrostics, mesostics, backronyms, and antiphons, all of which are meant to condense complex descriptions into tight bits of marketing and memory.
Some are words or near words, like SAMBA (a technology that could not be further removed from the act of dancing) and CORBA (a technology with close ties to the act of handling cobras). Others contain recursive structures (Gnu’s Not Unix, PHP Hypertext Processor). Some are redolent with the world weariness of there being too much software for too few letters (YAML: Yet Another Markup Language, YACAS: Yet Another Computer Algebra System). One ancient scanner protocol went by the title TWAIN (Technology Without an Interesting Name), as if to celebrate the joy of having any acronym at all. Acronyms are SCSI, after all. Or they would be, if that one was pronounced “sexy” (as was apparantly suggested) and not with the far less erotic “scuzzy.”
All of this reached a kind of apogee in the nineties, when someone decided to appropriate the ancient practice of rendering proverbial wisdom in acronymic form and apply it to the koans of the digital revolution. There was nowhere else to go, but to the appalling WYSIWYG — which is something like “whiz-e-whig” — “What You See Is What You Get.”
Among programmers, though, there were still greater whimsies to lay upon the general trend. Leave it to the Perl community to have come up with TMTOWTDI for “There’s more than one way to do it.” That one’s hard to pronounce, but less so if you agree to think of it as a name. “Tim Toady” was born. But after considerable discussion, the acronym had to be modified to embrace the hopelessly verbose, “There’s more than one way to do it, but sometimes consistency is not a bad thing either.” Where can one possibly go with TIMTOWTDIBSCINABTE? Perhaps only to an accepted pronunciation as completely ludicrous as the acronym itself: Tim Toady Bicarbonate.
As this brief (and highly selective, not to mention chronologically flawed) history makes clear, the purpose of using acronyms in computing is to make something appear to be other and better than what it is. In the case of DEC and IBM, the goal was to be something other than a lumbering giant from the old economy. With CORBA, it was simply to be something more suggestive of a bright, thrilling future than common object request broker architectures usually are.
But Tim Toady Bicarbonate was something else. Here was a highly controversial notion — possibly wise, possibly foolish — trying to masquerade as something settled. Software engineering pedants have been pulling this one ever since.
I call attention to this fact (which I will call an SF, or “Settled Fact”) not to ridicule the practice, or to subject it to the cold analysis to which Critical Code Studies is famously and rightfully averse, but rather to ask why it seemed particularly necessary to assert this truth (as an ambivalent truism) right at the moment when the so-called scripting languages were beginning to become the tools of choice for the Internet revolution. For surely, “There’s more than one way to do it” is obviously true. More than that, it manifestly cannot be otherwise. Why mention it at all?
And it really is always and everywhere true. Structured programming, and the attendant notions of encapsulation and data hiding, are predicated on the notion that a function that accepts, say, a positive integer and returns its square can do that any number of ways. Most of the attempts to impose order on software systems over the last several decades have arisen precisely to prevent such natural variations from metastasizing through the rest of the system. Modern functions — and even more, modern objects — are all about hiding the details and leaving their callers on a need-to-know basis with the mysteries within. The exact number of ways in which a given function might do its thing might even be provably infinite, if we allow for variations in, say, the number of meaningless blank lines we allow into the function body. At the very least, there are countless ways to generate a random sequence, sort a list, generate a hash function, or print out “countless ways.” It is not even true that representations closer to the machine are by definition less varied (as anyone who has ever tried to build an optimizing compiler will tell you).
Of course, what Tim Toady really means to say is that there is more than one rational way to do it. Everyone understands that the situation is rather like that of a person working through the middle game in chess. It might be true that the number of possible board configurations is larger than the number of atoms in the universe, but in practice, there are only about half a dozen moves that won’t result in your opponent calling you a patzer (a word we might usefully co-opt in computing as the opposite of “hacker”). A language designer, the argument goes, should therefore try to get you as far from the absurd moves as possible, and move you toward the moves that “make sense.”
But what, pray tell, makes sense? Critical Readers of code will see immediately that the comparisons with writing are stronger than ever. “Be clear,” as Strunk and White put it — an injunction about as useful as the order to “Be happy.”
One thing we can say for sure: Tim Toady, carbonated or no, was not an engineer. An engineer wants there to be One Way to Do It (however OWtDIouS). Even if there are two ways (to truss a bridge, or sink a piling), there should be a way to establish which one is the right one in a given circumstance (because the tensile strength of steel, the properties of concrete, and the hydrodynamics of rivers are, we hope, well understood). This is something like the ideology behind Design Patterns (celebrating its fifteenth anniversary this year). Yes, there is more than one way to do it. Here are the right ways. My own copy of that book (which dates to around the time of its first edition) has one of those built-in ribbon bookmarks, as if it were the Code of Canon Law — or better, the hymnal from which we should all be singing. It should come as no surprise at all that the authors of that book share a nickname with a power-grabbing faction functioning within a dictatorship.
Tim Toady stood against such ideas the way Aristotle’s enthymeme stands against the strictures of formal logic. It is good to speak in tight syllogisms. It is also impossible to do so and still be conducting work in the real world. It might be sloppy (rhetoric, as opposed to rhetoric), but there’s really no other way.
Everyone writes FactoryMethods with Visitors and Delegates and Flyweight Facades. Everyone tries to DoTheRightThing. But I believe that Tim Toady — expressed not as a idea or a conversation, but as an acronym — represented a shift in how we think about what is Right and Good. We no longer take it for granted that there is some kind of natural, inevitable fit between tool and task, language and expression, algorithm and data structure. We are no longer seeking that kind of truth. After Tim Toady, it started to seem that writing code was more like writing, where it is good to “be clear” amidst a thousand competing opinions about clarity.
IIGTBCAATCOAC, as they say . . .