So with all this software reuse, will our bank CIO still need a programming staff?

He'll always need a programming staff. That's one of the lessons of Backus' automatic programming. The moment you automate, you need to move on to the next level of value, because you are competing with your peers. But the CIO will need a different kind of programmer, one who can configure all the pieces and then write that little bit of code that does the special thing that differentiates the bank. The idea of the guy sitting alone in a cubicle writing code on a clean sheet of paper won't happen anymore. The model will be somebody who is broadly aware of a constant flow of new capabilities, assessing them, assessing risk and then putting everything together.

Do we need still more programming languages?

We are constantly getting surprised by languages. Before Java showed up, everybody thought we were done. The community resists change because it seems to be very costly and risky to move to a new language. But, yes, I think we will continue to make leaps forward in languages, and the leaps will have to do with how easy it is to express powerful thoughts as programmers. Some of the leaps will come from the language itself, but others have to do with the tools and models that surround the language.

What are some examples of these tools and models?

Microsoft, for example, is at the forefront of something called deep program analysis. They are deploying it internally in a very aggressive way. They are tools that will analyze your code and tell you important things about it. In security, for example, it will say, "Here's a potential buffer overflow," or, "Here's where you are not checking for a null reference." These code analysis tools and models are often slowly brought into the language itself.

Are software developers ready to exploit the concurrent processing possible in multicore chips?

I think it will be a lot of work to get where we need to be, partly because we have a culture of quality that's based on testing and [code] inspection. When you run in a concurrent environment, your tests are not repeatable, because you have intermittent problems. A problem might occur with a probability of one in a million, so if you run a test case, you have a very small chance of catching it. But if it runs every millisecond on every blade in your data center, the error might occur every few minutes.

A technology that I have been working on for some years is called analysis-based verification. Instead of running some code repeatedly, hoping you'll catch an error, you do a mathematical analysis that can tell you something about the full universe of all possible runs. That's been a dream for many years, and the challenge has been to make it scalable to big, messy programs and also to be usable by working developers. We have written software to do this and have tested it on commercial software at scale. It can say, "Here in your concurrent code is where a deadlock could occur," for example.