Is programming going the way of math?

At the roots, doing math and writing programs share a lot as human activities. Constructing reasoned arguments that fit an existing model of logical rigor, and fit into an existing framework of arguments is a basic mathematical activity. In programming, we construct fairly rigorous models of logical processes, which must be self-consistent and precise enough that an automaton may understand, and (clearly) fits into a large framework of such models developed by others.

Unfortunately, this is not how mathematics is perceived by most people (including myself, until recently, I’m embarrassed to say). Rather, math is taught from a young age as simply a toolbox of tricks that just work, and rather neatly fit together (although how they do so is rarely emphasized). One memorizes a sufficiently broad basis of tricks to cover the potential space of problems that will be encountered in a lifetime as a consumer, and then moves on to learn about other things.

It has always seemed strange to me, for example, that historians do not find it difficult to convince (most) people that history is not merely a listing of dates, but rather the hard work of elucidating the causes of and connections between past events, always searching for deeper undercurrents and contemporary relevance. People see this quite clearly with history, but less so with mathematics.

I fear that it is increasingly becoming the same way with programming. I recently read a very disturbing blog post that to learn programming from scratch, one should “learn to play with HTML and CSS first, and then maybe try some PHP.” The learn to play advice is excellent – if only this were offered to young mathematicians in grammar school! After the first three words, it all goes wrong. But HTML, CSS, PHP – these things are just big lists of formulas. You plug the right bits & bobs and hey! presto! it works!. This is by no means a tirade against those specific acronyms; it’s a tirade against the philosophy that they have anything to do with learning to program, the same way a mathematician might bristle at the suggestion that doing long division has much to do with learning to do mathematics.

Programming is NOT mastering a set of API calls and stringing them together in the right order! Math is NOT memorizing the quadratic formula and the chain rule and stringing them together! Lockhart’s lament, I have discovered, is true for programming as well. The flavor of e.g. Zed Shaw’s hacking, full of passion and original thought but mostly playfulness, is totally missing from the new generation of people who “got into PHP and now I build Rails apps”. And the way programming is taught in schools is even worse, as anyone who had to endure the AP Computer Science curriculum knows. It’s horrendous!

Had I my druthers, these universal laws of first-year programmers would be instituted:

1. New programmers will come up with their OWN ideas for programs. No new programmer will be allowed to write a program they do not feel like writing. Every new programmer must build at least one BIG program.

1. New programmers may read as much quality source code as they please – but they may not use it.

1. No budding programmer may use an API for anything except I/O. You want it? Make it.

1. No new programmer will be fed the standard list of data structures and basic algorithms in their first year. You want to store a bunch of things but don’t want to go through a whole list looking for them every time you want to get at one of them? Figure it out!

1. The ideas of coding in iterations and testing will be suggested, but not forced on the new programmer.

Sound familiar? This is the midnight lone cowboy hacker! The guy who’s been hacking at the unix kernel for so long is beard has fused with his keyboard. The guy whose departure from the company means they need to rewrite all the software because even though it works perfectly, nobody else can understand it.

Why on earth would I want new programmers to be like this? You’ll notice that this is also a model for painters, for musicians, and, indeed, for good mathematicians. I argue that before being indoctrinated with all the methodology, all the harnesses and frameworks and APIs and refactorings and design patterns, a programmer must learn how to write programs. These rules are designed to keep all of that distraction out of the way. After a year, when the person has developed their own ways of doing things, and developed opinions and frustrations and curiosities, reading the books will be meaningful.

Point being – don’t let programming go the way of mathematics. That’s the idea of these (totally unenforcable) rules. Don’t let generations of people grow up disgusted and uninterested because it seems like an utterly pointless set of facts that must be memorized. Don’t let a generation of people enter the practice, spend their time programming, but never actually think hard to write a real program on their own that does something. Let it be about dreaming up exciting (or useful) toys and then watching them churn away. Don’t make its teaching and its public face be that of a utilitarian, over-engineered toolbox. Save the art of it.