Infoworld has an article entitled "The seven most vexing problems in programming." The first two are "multithreading" and "closures."

I call bullshit. Neither of those are hard problems. Both of those are problems of programmer laziness. (Not compiler laziness, of which I've recently become a fan.) It's really hard to believe closures are a problem when we've had object oriented programming for over thirty years now and classes are nothing more than a specialized syntax for describing a closure.

You know what's really broken about these two issues? Mutation. Objects (in the abstract, categorical sense, rather than the OO sense) changing and being changed in the code in such a way that it's impossible to reason about the code in front of you. It's impossible to say "This is what the object is." It's impossible to say "This is what this function does."

There are times and places where mutation has a place, but they're actually exceptionally rare. Mutuation can be used when performance is the only thing that matters; but if performance is the only thing that matters, then locks, semaphores and monitors are the performance drags and your code shouldn't be involved with them.

Wayner's complaint is wrong. These issues aren't hard. These issues exist because programmers have been taught poorly. They've been taught that in-place mutation is the right way to do these things. They've been taught that lock-free data structures are "too hard" (but apparently debugging multithreaded is just fine). They've been taught to save unnecessary microcycles at the expense of their employers time and money.

The other day I debugged someone's code where he looped through a very large list of objects. There was a bug where some of the first items didn't get saved to the database with all the data the specification required. I discovered that he was pulling new data from the database every iteration, and saving some of it in a mutating array. Eventually it had enough data to do the job right, but not at the very beginning. When I asked him why he did it that way he said, "I'd have to iterate through the data twice, once to get all the keys, then to perform the updates. This was more efficient."

It was also broken. "You mean, you accumulate mutations as you go along?" I said.

"Yes." And then he broke out into a grin. "Isn't that called evolution?"

"No," I said. "99.999% of the time, that's called cancer."

And so it is with most programmers these days. They think cancer is preferable to thinking harder about the problem. I blame Python and Ruby, where mutation is easy, cheap, and often "gets the job done," but makes it much harder to understand what the Hell is going on underneath the code.