Languages for Bad Programmers

Bad programmers are linguistic victims and good programmers are masochists.

Brett Victor is going viral with an inspiring video on language and tool design (and philosophy). The language community has actually already made some strong strides in the directions he wants. Some of my favorite research is in tangible programming,  live coding, and omniscient debuggers.

Patrick Lam picked up on something else. As part of Brett Victor's philosophy that every code artifact should be directly (physically) manipulatable and understood, Brett believes requiring indirect manipulation and indirect understanding to be language design flaws. In particular, programming should not require mentally simulating an abstract Von Neumann machine that steps through your program. Not everyone agrees: Pat observed that, on the list of signs of being a bad programmer, the very first warning that you are a bad programmer if you cannot "run the program in your head".

Here's the thought. What would a language for bad programmers look like? Looking at the list of hacky "bad" programming practices, can you imagine a future where language and tool support will advance enough that they're the acceptable norm? The "bad" habits actually form an admirable set of goals for the language research community:

• Warning sign: Cannot simulate the program in their head.
  Goal: Get the computer to do the simulation.
• Warning sign: Have a poor understanding of the language's programming model.
  Goal: If I make basic grammatical mistakes when I speak, people correct me -- why doesn't the compiler?
• Warning sign: Chronically poor knowledge of the platform's features. Symptoms: reinvent language and framework code, "Email me teh code, plz" messages on forums, etc.
  Goal: Instead of viewing code copying as a bug, it's a design goal: I suspect *most* code today is duplicated, so I look forward to the future where the emphasis is on searching and synthesizing code rather than learning and writing it.
• Warning sign: Struggle to comprehend pointers. Symptoms: failure to implement a linked list, allocates arbitrarily big arrays, inability to find pointer arithmetic bugs, etc.
  Goal: raise the level of abstraction so programmers don't have to think about these issues.
• Warning sign: Have difficulty seeing through recursion.
  Goal: Thinking concretely should be fine, and the tools should walk you through the base cases and generalization.

You can apply similar reasoning to the category of "mediocre programmers" and, my favorite, "pinball programmers". Pinball programmers struggle with edge cases, or simply do not care. They can be a security disaster. Again, however.... so what? These types of problems are exactly what we built computers to solve: rote grunt work.

The shocking conclusion of the bad programmer essay is the signs that you shouldn't be a programmer. If you cannot determine the order of program execution, cannot think abstractly, poorly organize your code as an ever-expanding ball of mud, believe the code and runtime are unreliable, or simply don't care about much of the code quality, you shouldn't be a programmer. Hogwash!  If these traits are required for programming, our ability to write code that keeps growing in ambition by magnitudes seems doomed. I can fairly neatly bucket these warning signs as inevitable programming realities (massive and concurrent code on unreliable hardware) and goals ("search, don't sort"; declare what instead of how).

Maybe the programmers aren't really all that bad. It sounds like today's languages are the stupid ones.


(Updated 1/26/2013 with minor editing.)