Tuesday, October 12, 2004
  Beware of the Turing Tar-Pit

in which everything is possible but nothing of interest is easy.
Alan J. Perlis

What is the Turing tar-pit? It’s the place where a program has become so powerful, so general, that the effort to configure it to solve a specific problem matches or exceeds the effort to start over and write a program that solves the specific problem.

I suffer from a tendancy to go swimming in tar. I start out trying to solve a specific problem. I become frustrated with the obvious deficiencies of the tools, and before I know it I’m sketching out ideas for platforms, frameworks, and architectures to solve a whole class of similar problems.

(This is especially dangerous for programming language designers. There’s an irresistable urge to reduce a language to the smallest, most elegant core of axioms.)

I think a programming language should be mostly defined in itself. A language spec should be divided into two parts, a small core of operators that play the role of axioms, and the rest of the language, which, like theorems, are defined in terms of the axioms.
Paul Graham

The danger of the tar-pit is that instead of developing a solution to a problem, you develop a tool for solving problems. And invariably, the wider the class of problems the tool can solve, the less useful it is for solving any one problem.

In my own case, I often find myself engaging in “bottom-up programming,” trying to invent the perfect programming language for expressing the program I’m trying to write. When I find myself working on language syntaxes, I realize I’m mired in tar and I need to reset.

The Turing tar-pit’s lure is that it is situated right in the centre of some of the most attractive real-estate in your imagination. Tools that solve whole classes of problems in generic ways offer the potential for vast improvements is productivity. Consider VisiCalc: this application actually turned its users into programmers!

In programming, everything we do is a special case of something more general—and often we know it too quickly.
Alan J. Perlis

The very exercise of trying to understand the relationship between the problem you’re trying to solve and the general class of problems can help you understand your problem in more detail. And you can get some wonderful Aha! moments.

So I believe that to do really great work, you must be prepared to skirt very close to the edge of the tar-pit. Hopefully you have an iron will and can avoid disaster with ease.

In my own case, I have little will and I’m further hampered by an enormous curiosity. Out of self defence, I’ve developed some heuristics for exploring the edges of the tar-pit and mining generalization for insights:

  1. Keep Alan Kay’s words in mind: “We aim to make simple things simple and complex things possible.” When solving the general problem makes complex things possible, that’s good. But it shouldn’t be at the expense of making simple things simple.
  2. Mentally retrace your steps to the safe safe ground of the problem domain on a frequent basis. In my own case, I work with fairly disposable user stories. The important thing I do is return to them every once in a while and ask “how will this marvellous widget make any of these things easy?”
  3. Eat your own dog food/go round trip on an infrequent basis. Okay, you’re convinced you need to run your application inside a special purpose virtual machine. Fine. Pick one small operation and make it work. Program for your virtual machine, end to end. Don’t skip any of the steps. It’s better to go thin (few functions) and deep (use the entire stack) than to go wide and shallow. If your VM is a pain in the rump, you’ve discovered something. (This is a cornerstone of Ken Schwaber’s Scrum methodology).
  4. Don’t beat yourself up if you get mired. If you never produce anything more than an esoteric programming language or tool, you’ll still have gone where strong minds fear to tread. Okay, your started out trying to solve problem A and you found yourself solving a general class of problems C that doesn’t even include A. Once again, Alan Kay: “A successful technology creates problems that only it can solve.” Don’t be so sure you haven’t created something really important. Finish it up, you won’t know what you have until you start using it.

Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?

Edsger Dijkstra




Comments on “Beware of the Turing Tar-Pit:
Just wanted to say I thought this was an excellent and well thought out post. I often suffer from this. I have called it feature-creep before. Now I have a better name.

Thanks! Great point.

The scary thing about the tar-pit is that it doesn't feel like feature creep: you aren't adding a lot of cruft to your design, in fact you feel like you're making it more elegant.
Exactly! It's not feature creep; it may even involve removing features. Instead, it's a much more insidious form of scope creep. But I like the image of it really being the feeling of the tar sucking you down...

--Kai MacTane
Where I get into trouble is when I run over the top of the tar really fast. Often this comes in the form of "making commonly changed things easy to change." It creates architecture. Sometimes that architecture is simple, straightforward, and easy to implement, sometimes it gets out of hand (as in, sometimes I make it to the other side of the tar, but others I am breathing bubbling blacky badness).
Meta-solutionising is a common trait in programming. It's enshrined in job titles: I started as a Programmer, became a Software Engineer, now I'm some kind of "Architect". Mostly I deliver applications... so what changed?

Out of the Turing Tar Pits come wholly unmaintainable systems written by people who long ago left the company (lava flow). One reason I linger round the Tar Pits is it makes the work SO much more interesting - let's admit it.

Now, I'm going to try to shake some tar off.
Does Josh' comment suggest more of an iced over lake metaphor?
This is sort of a rewording of #2, but in general you want to avoid predicting what might be needed someday, and just focus on the problem you are trying to solve now. If a bottle opener is what is needed, don't write a swiss-army knife. Like you say, though, there's a fine line to tread here; certainly you want to strive to make it easy to add functionality going forward - just try to make your architecture flexible, and resist the urge to make it do everything right at the beginning.
brilliant! brilliant! wonderful!
well, pretty decent anyway.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /