Waltzing and Programming are the Same Thing


Have you ever waltzed? I mean truly waltzed, not just going through the steps. When you really waltz it is an amazing thing – you and your partner lean away until you perfectly counter balance one another. The three beat movement becomes effortless as the angular momentum of your turns sustains the motion. Suddenly, you're flying, you and your partner's bodies intimately interconnected by physics.

I see programming, especially multi-threaded programming, as an intimate dance similar to waltzing. In my mind, programming is motion in many dimensions. The motions trace out patterns. Views from different perspectives reveals orthogonal structures. From one perspective, I can see the structure of execution repeatedly surge outward into complicated recursive fractal curves only to withdraw back to singularities. From another perspective, almost as if I've taken the program and rotated it ninety degrees in my mind, I see the code structures, objects, inheritance, functions as if they were elements of a crystal lattice. Rotate again and I see the semantic structure of the information transforms within the program. With dimensionality that I cannot hope to project onto this page, I can spin the program on different axis to reveal structures and, most importantly, inconsistencies.  Like waltzing, its all about balance of opposing forces coupled with motion.

So many times in my forty years of programming, I've discovered subtle bugs in software design, not because of problems in data, but because I see in my mind a “discoloration” in the motion in one perspective that isn't evident in another. I may not know what the problem is or how it will manifest, but I see the region as literally emitting the wrong color.

Way back in graduate school in my artificial intelligence class, the professor was showing a recursive pattern matching algorithm in Lisp. I was daydreaming and was jerked back to class by a flash of blue on the overhead projector screen. Confused, since the professor was using only black ink, I interrupted him saying there was problem in his algorithm. I couldn't express what the problem was, and I wasn't going to say that it was too blue. I pointed out the location and said something vague about the recursion losing its context at that point. I was right. After staring at his code for a while, the professor looked up and grinned at me: he canned the example that he had been using for years. I rewrote it for him in his office after class.

I truly love multi-threaded programming. It adds more dimensions from which I can view a program. Imagine multiple couples waltzing and each are swinging and trading chandeliers among themselves as they glide through their turns. The chandeliers pass through one another, perfectly meshing, never hitting. Slower dancers do not hold up faster ones because the dance floor itself warps and bends to keep everyone synchronized. The chandeliers are data structures, the couples are threads of execution, the dance steps are the algorithms, the music is the machine.

This is my first time ever to try to put my programming brain processes into words. I've alluded to the dance metaphor in the past, I really do see software systems as interlocking curved motions. You'll often hear me state that programming is performance art. Dancing is pretty clearly performance art. You now understand the reason behind my metaphor. Good software is like skilled dancers waltzing in perfect balance. Ironically, I rarely ever dance.

I assume the color thing is a form of synethesia. A good program will have a balanced glow in yellows, greens and browns; earth tones. Problems show as blues and purples. For some reason, software never appears red to me. You know one of the most unfortunate things? Many of the edicts in Python's PEP 8 gives code a bluish cast. Truly, that's a sad thing as it is likely to eventually drive me to some other language.