Programming models

I used to have a book on 6502 assembly language programming back in the days when I was trying to recreate the arcade game Defender on my Atari 800. I think I may have forgotten most of what is in the book. I do remember that A9 is hex for LDA (load accumulator) but I can’t remember which of the index registers did which kind of indexed addressing. But the term that stuck with me most was the concept of Programming Model.

For the 6502 the programming model was basically the register set + the 80 or so odd CPU instructions. This was the model that you worked with and this level of abstraction was pretty much in your face all the time. These were the tools you had or the model you had to work with.

23 years later, the level of abstraction has increased dramatically but the concept of a programming model is still with valid. Even if you are building a huge C++ application with tons of external libs you still are working with a programming model whether you know it or not. Its important to work with a model you understand or else you will find your absrtactions leaking.

In most of today’s programming environments, the features you have to choose from is huge. In C++ for example you can define basic concepts about how objects are allocated, referenced, accessed or copied. This is good and bad. While no individual programmer thinks he needs limits placed on his choices, when a team is working together it is usually necessary to restrict the programming model to a subset of the available choices. When someone complains about this, usually by explaining why they should be allowed to use some esoteric language construct because they understand it, I remind them that rules aren’t for the brilliant ones but for those “other people”. Sure I want YOU to have all the power in the world, but we can’t trust that other guy with it.

Choosing a programming model should be one of the first steps when starting a new development project. You need to go way beyond just saying we are going to use c++ and cvs. You want to clearly define your object model and decide what features of the language will be used in your project. This usually takes the form of coding conventions. But that Idea usually gets bogged down in issues of tab stops and under_scores versus MixedCase. These kinds of discussions while necessary, will often bore the best and brightest members of the team to the point where they are sleeping when the important issues come up.

Some examples of those are (for c++)

• Will we use the STL and for what?
• What kind of debugging/logging system do we need?
• When is it ok to use Multiple Inheritance?
• What are acceptable uses of friend?
• When should exception handling be used?
• How extensively will we use templates?
• What external libs will we use as part of the programming model?

The maximum number of people that should be part of deciding the answers to these questions is 2 and only if they get along well. Spending days in a conference room with 8 coders trying to show up each other with their knowledge of the proper use of the const directive is how I will spend my time in hell if that’s where I end up. The model is something to be designed and created not discussed and debated. If you feel like you can’t escape the need to get everyone’s opinion then go to each of them one on one and get their views and then make a choice. That technique works for alot of things btw. But that’s another post for another day.

Some people tend to build their apps using alot of external libs. For some applications this in unavoidable. You aren’t going to make a 3d game these days without DirectX or OpenGl for example. But even though those libs might seem important, they aren’t part of the programming model. They are simply extenders for the application. In a video game with over 500,000 lines of code. There might be only a few files which actually use those libs. So its not really a part of the programming model for the whole team.

Since buying code is almost always cheaper (in the short run) than building it, some people try to use external libs as part of their programming model. In my experience that almost always ends up being a bad idea. Sure, Boost might have some cool smart pointer class but having something so basic (in that it could be in almost every file) being from an external source can get you into trouble. The leaky absrtaction problem will almost always bite you even if you don’t have to deal with plain old bugs in the third party’s code.

Besides the compiler itself (and maybe STL)there shouldn’t really be any part of your programming model that is externally supplied. If you can’t write it yourself you probably shouldn’t be adding it to your list of things you depend on. Each dependency or abstraction is a risk. Some, like using a compiler are worth it. Others are not. Making the right choices for your project can make all the difference.

Notice that none of the questions in the list above have to do with development environment (IDE) choice, build system, or even the actual Architecture of the code you are making. The model you choose can be pretty separate from all of those issues. Those things, along with Use Cases, Requirements Definitions and the like get alot of attention in the early design phase of some software projects. Often people assume that the programming model as I’ve defined it here just comes out of the other concepts. Usually it doesn’t and you see the result in the code months later. In alot of projects coders will complain that the code is ugly, junky, or even kludgy. You might think that comes from bad architecture or just bad programmers. Of course both of those can happen but more often I think its the result of a bad model.