When clock speeds stop increasing

I look forward to the day when clock speeds stop going up.

When the day comes, I'll be able to buy a computer and keep using it for five, ten, maybe even twenty years. The last several computer purchases that I have made were driven not by any problems with my current machine, but by the fact that new software keeps needing faster and faster computers. Once the computers stop getting faster, the speed requirements from software should stop going up.

Most developers will not be moving to an arbitrary-number-of-threads model. They may use a few threads for things like doing something asynchronously or keeping the UI responsive. This means that doubling the number of cores in a chip won't help most applications past 4 or 8 cores.

Right now, the constantly increasing clock speeds help to hide terrible code. If something is too slow on today's computers, don't worry about it. It'll run fine on the computers that will be out in 18 months. Once the clock speeds stop increasing, developers will need to start caring about efficiency again. The quality of a piece of code might start mattering more than the time to market. We'll finally get software that is focused on performing its core function well instead of on adding every last bell and whistle that the marketing department can think up while implementing all of them poorly.

Open Source software will catch up to proprietary software. The only way for proprietary vendors to stay ahead of Open Source software is to write new code faster than the Open Source community does. One common way of writing code faster is to worry less about its quality and efficiency. Once the proprietary authors need to worry about efficiency, they won't be able to turn out crap as fast as they do now.

Wither imperative programming?

I write imperative code. Code with reassignment statements. Code that mutates data structures. Code with side effects. There. I said it.

In fact, it's even worse than that. Most of the time, the primary purpose of my code is the side effects. I don't write much code to figure stuff out. Sometimes I do, and when I do I try to program in a purely functional style as much as I can. But the fact is, most of the time, most of my programs exist for the purpose of doing something, not figuring something out.

Sometimes I structure my code using objects. Sometimes I just make libraries that each contain related utility functions. Sometimes I use closures. Whatever route I take, there are almost always important parts that are shamelessly imperative.

I mentioned in my last post that I mostly read old books. This is partly out of interest in history, partly because I have a greater interest in the subjects that were popular in the 1960s and 1970s than the subjects that are popular now, and partly because some of them are just great books that happen to be old. But I recently noticed something else that distinguishes my old books from my new books. The old ones talk about imperative programming!

They talk about how to use assignment statements and side effects, and how to write loops that contain assignment statements and side effects, and how to think about this code and how to write it and how to convince yourself (with a formal proof, if necessary) that it does what you want it to. I don't know of any recently published books that discuss this stuff. Do you?

Why is this? Are recent authors under some kind of delusion that because imperative programming is difficult we aren't doing it, and thus there's no need to talk about how to do it? Are the academics so focused on type systems and concurrency and functional programming that they no longer consider imperative programming interesting enough to write about?

What would you like to hear my thoughts about?

I'm trying to get back into the swing of posting, and I'm trying to figure out what to post on. I've got a whole slew of things bouncing around in my head, and I figured I'd offer you, that is, anyone who is still following my blog after the long dry spell, a chance to weigh in on what I should write about first.

I could write reviews of programming books for a few years. I read a lot, especially old stuff, much of which is under $5 used these days. Do you want to hear about my favorite books? What subjects? Compilers and interpreters? Lisp? Writing good code? Designing programs? Old programming languages?

I have a hypothesis that programming salaries (and all technical salaries) are going to go up again, and a few links to news stories that I might be able to weave into a cogent argument. Any interest?

I spend a lot of time looking into my crystal ball wondering what will happen if/when the relentless increase in Mhz stops. Do you care what I see?

I love strange and forgotten corners in the world of programming. How do you implement recursive functions in an interpreter that's purely functional? How do you optimize tail calls in a language with dynamic scope like Logo? How do you handle functional arguments and functional values in a dynamically scoped language like Lisp 1.5? What if you want to use shallow binding? I've never had any use for any of these tricks, but I still find them endlessly fascinating. Am I the only one?

I can complain about some common excuses that people use to make stupid decisions.

I can talk about my own opinions on how to write good code.

I can talk about some of my favorite themes that keep appearing over and over in the history of programming.

I can do a series of posts about Microsoft. History, practices, ways that I see them preparing for the future, strengths and weaknesses, predictions, etc.

I can talk about the good old days online (before the web), and all the things that are worse now. I could talk about the things that are better, but I'm not sure there's a point. You probably know them already.

I could go on, but that's enough to get started.

Programmers Who Read

I just read The Programming Elite, Programmers Who Read. Apparently Joel Spolsky claims that only 5-10% of practicing programmers "read things in order to better themselves as programmers."

I find this very depressing. I also find it completely believable. It helps to explain how people keep reinventing things and thinking that they are new. I recently went to a lecture on Great New Thing and afterwards I was complaining to a friend of mine that more than two thirds of the lecture was about ideas from structured programming, but with new names. My friend didn't disagree with me. He just asked why I keep being surprised that nobody knows any history. Apparently I've made similar complaints often enough to bore him.

I guess I just don't get it. How can someone program and not want to read everything that they can get their hands on?