Originally published on Indelible Blue Pen
Programmers have an odd obsession with acronyms. We pepper our conversations with them until it sounds like we're speaking a foreign language, and I'm not entirely sure that isn't the whole point.
There are two rather pesky acronyms that, once uttered in general programming territory, will start either a heated debate or an all-out war.
Those acronyms are TMTOWTDI [There's More Than One Way To Do It] and TOOWTDI [There's Only One Way To Do It].
For years, I've been a proponent of TMTOWTDI, despite having no experience in the Perl community, from whence the acronym comes. It was just logical to me, especially given my stance that programming is an art, and not a science. I merely picked up the acronym in passing, finding it a good paraphrase of my own phrase: “There are at least a hundred ways to accomplish something, and about ten good ways.”
However, my first real programming language was Python, and we get TOOWTDI from that community. It is derived from Tim Peters's The Zen of Python.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
It doesn't take a logician to figure out that we're not on the same page. Part of that is to be expected – Perl and Python are two entirely different languages, built around two entirely different philosophies! However, as time went on, I began to spot something wrong…and it was the same problem in both camps. Programmers were writing bad code, and citing their favorite acronym of choice to justify it.
Have we missed the point?
The Paradox
Living in the C++ world, I've long known the upsides and downsides of TMTOWTDI. Used appropriately, we find some pretty spiffy innovations. Used inappropriately, we get crappy code with that acronym stamped on it. Frankly, the dichotomy was starting to drive me crazy.
Then, a recent project prompted me to pick up good old Python again. As I began to get re-immersed in that language, I wandered into #python, the IRC channel where I had taken my first shaky steps as a programmer all those years ago (shout out to nedbat and _habnabit for breaking me in back then!)
It took me a few days to remember that it was Python that gave us TOOWTDI, which seemed contradictory to everything I had observed in the coding world. I have even discussed the most puerile and venomous proponent of misapplying this view, Programmaticus Militaricus, in A Field Guide to Common Nerds for the past few years. Yet, as I watched the conversations in #python, I didn't see any of that nonsense from the regulars, no matter how experienced they were. They were somehow upholding The Zen of Python without quashing innovation.
I had a long conversation with another coder on this topic, through which I began to probe the mindset behind TOOWTDI. I concluded that there were two distinct (and largely incongruent) arguments for the theory:
“We always do it this way.” (May also be called “pattern recognition”).
“This way is known to work the best.”
I've seen both uses in the wild. Under view #2, we find some pretty spiffy innovations. Under view #1, we get crappy code with that acronym stamped on it.
Wait a minute, that sounds familiar...
Rabbit or Duck?
That's when it hit me: if both camps were seeing the exact same benefit for appropriate use, and the exact same drawback for misuse, are we really sure they're waving different flags?
The issue tends to look like that rabbit-or-duck illusion. The “one way” camp takes issue with the “many ways” camp because of the sloppy code and disorganization. The “many ways” camp doesn't like the “one way” camp because of the rigidity and apparent blindness to innovation. But when you tilt your head to the right and squint, you realize that sloppy coders and rigid programmers are both lazily indifferent to the innovation of other coders.
In other words, all the dweebs are suffering from another acronymized condition: NIH [Not Invented Here].
The problem came when two camps saw only half of the problem. The “Tim Toady” (how we pronounce TMTOWTDI) camp said “We must address this problem of rigidity!” Meanwhile, the TOOWTDI camp said “We must standardize effective approaches to encourage adoption!” The NIH sufferers bolted for whichever camp provided the best excuse for their inherent laziness, and both sides concluded that the enemy must be the people on the other side of the field – the ones that resisted standardization or decried flexibility.
Of course, I'm painting a word picture here, but if I know my programming history, both movements did start somewhat around the same time, and they only concluded the other was a problem after the fact. Actually, Guido van Rossum and Larry Wall are on quite pleasant terms with one another, according to Python's beloved BDFL:
The funny thing is that while there is a lot of animosity in the lower ranks, I've actually been very friendly with Larry Wall and Tom Christiansen ever since we met five years ago at the VHLL symposium that Tom organized.
All that to say, I think we missed the point of both acronyms.
Two Hammers, One Nail
When you take away the acronyms and have an honest look at how the gurus in both camps approach coding, you find there really isn't a massive difference.
For example, a conscientious TMTOWTDI programmer doesn't use his banner as an excuse for sloppy and inefficient code. He follows the community-accepted standards as far as is reasonable, uses the common algorithms, and avoids design patterns known to cause problems. He'll use Quicksort over Bubble Sort any day of the week, not because Quicksort is the “one way to do it”, but because it is proven faster, and thus is the right tool for the job.
This generally unspoken half of his coding style is absorbed into the lengthened version of the acronym: TMTOWTDIBSCINABTE (pronounced “Tim Toady Bicarbonate”) – there's more than one way to do it, but sometimes consistency is not a bad thing either. (We really do have a problem with acronyms in this field!)
Meanwhile, a conscientious TOOWTDI programmer doesn't use her banner as an excuse for mindless adherence to “the way we always do things”. She is always looking for ways to make her code faster, cleaner, and more effective. She knows that the true Pythonic means of accomplishing any goal is going to be the fastest and most elegant, and she uses that means because of its own inherent merit, not just because “everyone does it.”
As simpson pointed out in #python, “The ‘one way' should come with an optimality proof.” The best way should be provable, and better ways are being discovered all the time. We should be seeking the objectively best solution to the specific problem, and true Pythonistas do exactly that.
If we reexamine The Zen of Python, we quickly realize that for most of those single “obvious solutions,” we aren't Dutch. We don't know the language as well as the guy that wrote it, so we don't always see the shortest and most effective path to where we're going. As soon as someone finds a better way, the rest of us all facepalm in unison because we missed what has now become obvious.
When you view the issue through that lens, you realize that both camps are aiming for the exact same goal: to find the most effective and elegant solution. TMTOWTDI reminds us to remain open new ideas, while TOOWTDI reminds us to aim for the best available solution. They're two sides of the same coin.
Of course, we must remember that every specific programming problem is fraught with subtlety and interconnectedness. None of us will ever know all of the “current best ways” because none of us can even imagine a hundredth of all the possible specific problems. Besides that, those “current best ways” are always being replaced by better ways, on and on, until we're running on a treadmill of innovation trying keep up. Perhaps that's one of the wonderful things about coding – there's always something new.
Before we take down our TMTOWTDI and TOOWTDI banners, I should say that they have their place. The Zen of Python defines the Python language itself – there should be one obvious way to do things. Meanwhile, “Tim Toady” defines the Perl language itself, a language that lends itself to experimentation. One doesn't replace the other: Python and Perl both have their place, alongside the hundreds of other unique programming languages.
All that considered, perhaps we need a new acronym for how we solve problems – one that cannot shield inherently lazy coding of either kind. I'm no Tim Peters, but I propose the following:
TAMESFA: There's a more elegant solution for anything!
While there might be some rare situations where this is not the case, I think it's a pretty safe banner to wave. After all, even algorithms long unchallenged are finding new and unexpected competitors!
What do you think? Can we unite under a new acronym and move forward towards better and better solutions together? Is there another part of this historic rift that I've overlooked? Please leave a comment! (Just be nice.)
Image Credit: “Mocking Bird Argument” by Chiltepinster is licensed under CC-BY-SA 3.0.
Top comments (2)
I’ve never heard of these long acronyms before (I’ve heard of NIH) but I’m not surprised they’re out there. Very interesting similarity they show; it really is like the Duck and Rabbit analogy that you pointed out. Thanks for the long acronym pronouciation hints by the way; I had been scratching my head wondering how to say them.
TAMESFA sounds like a good one as it does cover the common ground between the Tim Toady and Too Toady camps. I guess it won’t work in a time restricted situation (e.g. hackathons, coding competitions), but would be lovely in a not as timed constricted environment. I’m not sure how to pronounce it though.
How about "tame-es-fa"?
I agree, how elegant you can actually make the code is time-dependent, but that's a whole other topic of discussion and debate, to be sure!