Imperative Programming to Start: Please!

Imperative ProgrammingNormal people don’t even know what imperative programming is. Even most programmers are at most vaguely aware of the different classes of programming languages. But there are a lot of programming paradigms.

For example, there is logic programming, which is unlike what most people even think of as a programming language. You can get an idea about it by checking out Prolog. In it, you don’t say, “Do this, then do that.” You define relationships and then ask the system questions. It’s pretty far abstracted from what a computer is actually doing. And the same is true of the object-oriented programming paradigm. And this is why people should stay away from these kinds of paradigms when they first start coding.

My big boss sent me an article recently, 30 Years Later, QBasic Is Still the Best. In it, Nicolas Bize talks about how he introduced his son to programming with QBasic and how easily his son picked up on it. So QBasic rocks, am I right?! But he doesn’t dive into why QBasic worked so well for his son. Because the issue is not QBasic or the Basic programming language at all. The issue is that it is easiest to learn simple imperative programming languages: languages where you tell the computer, “Do this, then do that.”

The reason is that they model the natural way that we go about solving problems. Here’s an example of a bit of imperative programming that pretty much everyone has written:

IF "Man on sidewalk ahead is having angry conversation with himself"
THEN "Cross the street."

In more traditional code, it would look like this:

crossStreet = 0;
crazyBehavior = 1;

if crazyBehavior = 1
  crossStreet = 1;

In object-oriented programming, it’s far less direct. The man would be an object. One of the object’s characteristics would be crazyBehavior. The object would have functions for setting and reading crazyBehavior. There are lots of reasons why this is a better way to code. And one of those reasons is that it makes the code more abstract. But that also makes it that much more difficult for someone new to programming to learn what’s actually going on.

When I first learned to program for Microsoft Windows, it was in the imperative programming language, C. The basis of every program was running a function that returned any messages that had been sent to the program. Then, the program would loop through all the messages that it was interested in. Is the message to redraw the window? Then I’ll do that! Is the message to resize the window? Then I’ll do that! And so on.

But later, I wrote everything with C++, an object-oriented language. In that, these was no checking for messages. Instead I just wrote functions for objects to do the things that needed to be done, and all that messiness of checking messages was gone. Sure, it was still in the code somewhere. But it didn’t involve me as a programmer. And if I had never coded the old imperative programming way, I wouldn’t have had much of an idea what was really going on.

Computers are stupid. So the closer you are to how they really work, the easier it is to understand. It just so happens that the closer you are to how they really work, the more work you have to do. So there is a very good reason to program using high level abstractions. But it is no way to learn.

Yet Nicolas Bize is in the minority when it comes to programmers. If you ask most programmers what language you should learn because you are just starting out, they will usually scoff at things like Basic or Fortran or even C. Personally, I think people who want to learn programming should start with some form of simple Basic. Then they should learn assembly language or take a course in digital electronics. Then they can branch out into other languages where they can be more productive. But by that time, they will understand how computers work.

Leave a Reply