Sutherland and Myer’s On the design of Display Processors, a fun paper from 1963, is about the nature of progress—it often comes in loops.

As it was found that successive improvements to the display processor design lie on a circular path, by making improvements one can return to the original simple design plus one new general purpose computer for each trip around.

Early terminals had one chip to handle everything, and a lot of time was spent handling the graphics. So to speed things up, they offloaded the work to a new special purpose chip—something in the background that reads a bitmap from memory and displayed it. They could make drawing faster by pushing more work onto this chip—if it did points, then they could extend it to draw lines and shapes, and then why not store shapes for drawing, too.

Eventually, the display chip turned into a complete CPU, supporting subroutines, operations and data structures. Things could still be faster—While it was managing shapes and high level drawing, something else could draw the bitmaps. So they built a new special purpose chip–

Gradually the processor became more complex. We were not disturbed by this because computer graphics, after all, are complex. Finally the display processor came to resemble a full-fledged computer with some special graphics features. And then a strange thing happened. We felt compelled to add to the processor a second, subsidiary processor, which, itself, begau to grow in complexity. It was then that we discovered a disturbing truth. Designing a display processor can become a never-ending cyclical process. In fact, we found the process so frustrating that we have come to call it the “wheel of reincarnation.”

I’ve witnessed a similar occurrence—Memcache is introduced to take some of the load off the database. A simple cache to begin with, but eventually someone asks — why can’t we do queries on the cached data — and so a few more operations are added. Slowly but surely the special purpose store bloats until it becomes a database in its own right. Then memcache is introduced to take some of the load off the new database.

It was not until we had traveled around the wheel several times that we realized what was happening. Once we did, we tried to view the whole problem from a broader perspective.

The cache protocol starts simple, but eventually more commands are added as features are desired. In contrast, HTTP caches don’t tend to expand in this way, as the protocol keeps them simple. Maybe If you’re wanting to do more with your cache than store results, you may need a better database rather than a smarter cache–

General computing power, whatever its purpose, should come from the central resources of the system. If these resources should prove inadequate, then it is the system, not the display, that needs more computing power.

One of the reasons they could constrain the power of the display processor was that the physical distance between display and mainframe—client and server—was fixed. Making the display chip powerful didn’t make sense when there was a powerful chip nearby.

If the display must be located far from the main computer, then the problems of data transmission dictate that it have at least a local memory. Likewise, there are arguments for detaching the display from a parent computer that is running a time-shared system.

When you have widely distributed systems, latency means general computing power can’t always come from the central resources. HTTP caches become rather powerful when they’re Edge caches. Sometimes it’s ok to make something more powerful, without being trapped in a loop.

This decision let us finally escape from the wheel of reincarnation.

Maybe all unconstrained subsystems will always become general—in the same way languages will grow until they are turing complete, and programs grow until they can read mail—or they’ll be replaced by more general ones. Or as Rob Pike put it—Writing programs that do one thing and do it well “is dead and gone and the eulogy was delivered by Perl.”

If you find yourself going back and forward, either you don’t have enough constraints, or the constraints keep changing underneath you.