Brass Bullets

Have you read "No Silver Bullet"? It's kind of long, but here's a super-quick summary:

Programming is difficult. There are two reasons: difficulty in expressing ideas to the computer, and difficulty determining what to express in the first place. High-level languages have taken most of the work out of expressing ideas (vs. machine code), so the remaining difficulty is almost entirely one of figuring out what exactly to program.

The idea of a "Silver Bullet" develops from the first paragraph of the paper, where Fred Brooks compares the problem of software complexity with werewolves, mythical monsters that only die when shot with silver bullets.

Software complexity is no joke, but it's also not mythical in proportion. It's just one reagent in a system of constraints. Frankly I think people are much more complex than software, but thousands of years of history has taught our society some good ways to manage that complexity which is known as human behavior. Thus, we don't think of it much.

Another constraint is the difficulty of expressing a concept in a format that the computer can process. Higher level languages make the biggest difference here, but libraries and environments also contribute their fair share to getting the job done.

The essential constraint which Fred Brooks so verbosely gets around to is deciding what to program in the first place. If you can solve that, then you have your silver bullet. There is no complete solution, but a sound design method can help quite a bit here. Brooks was sweet on top-down development, but a more current practitioner might vote for extreme programming.

But lo! We already have our silver bullets. I have just described them, but they go unnoticed and dismissed as mere brass bullets, destined for inadequacy in the larger scope.

Let us look forward from a vantage point in the past and trace history as it happened. Way back when programming meant writing machine code, it took some brilliance to even contemplate writing the program which writes programs which we now call a language compiler. Still, that made all the difference. Barring ubergeeks, programmers no longer thought about hardware, but instead of a mathematical model of computation. This made life much easier.

Fast forward to the weeks before structured programming was academically described. (Or think about using BASIC with line numbers.) There were conventions for how to do iteration or recursion on explicit or implicit stacks, and it was cool to be able to write a program to solve the Towers of Hanoi problem. Structured programming takes these conventions away from the programmer and places them instead in the hands of the computer and the compiler, such that the programmer no longer thinks of them. Instead, there are loops and functions and procedures and logical branches as fundamental elements of expression. Soon enough, rolling your own control structures with GOTO became outlawed. Again, we took a convention, which involved active thought to follow it, and we turned it into a computer program, which required no thought.

Now in larger systems, programmers naturally found themselves organizing modular structures that acted a lot like what we finally formalized in object oriented programming. That's probably why Simula never gained the popularity of C++ and Java. A critical mass of programmers had not developed a convention yet, so only the prophetically gifted could see the benefits of automating that portion of the code generation which we now call a class hierarchy. Bjarne picked the right time, place, and circumstances to play ubergeek, didn't try to blow up the universe, and instigated a sea change in software development.

Each time the common paradigm changes, programmers gain access to the resources needed to manage dramatically more complex systems than before, while carrying on only incrementally more thought processes. Code size goes down, and consequent productivity goes up.

When Ericsson, a telephone switching system vendor, found its software complexity system untennable, they did a lot of introspection and research. The result was the new programming system called "Erlang", which is a language and a runtime designed around a set of core ideas that fit well with the general problems that Ericsson had to solve, both technical and human.

Ericsson's first product to use this new programming system was delivered with a tenth of the effort and with something like no bugs. So as compared to working in C or C++ or whatever it was, this would constitute a silver bullet. Of course, it did take time and brilliance to develop the E language in the first place.

Obviously, Erlang isn't for everyone, but I think we can learn from their experience. Is your programming language forcing you to do more to express yourself than you should?

To get programming power, there's really only one route: minimize the number of things that a programmer has to think about to get a working system. There are many ways to approach that, but I think that this unified approach should guide the further advancement of our field.

IBM says that machines should work, and people should think. But if programming is thinking work, then the ideal programmer makes the machine do the thinking. In a future article, I'll explore some ways I've made the computer do the thinking.