Coping with your first programming class

I'm posting this here for the benefit of some former students:

If you'll bear with me and read all of the following, I think it may help you a lot in the programming class. The summary is: use pseudo-code (English) to write out what you want a program to do, then turn it into whatever programming language you're using, and you'll be much more successful.


Beginners in programming, especially those who don't find programming an interesting and attractive pastime, have many struggles.

There are always two problems in programming: first, what do you need to do to solve whatever problem you're working on (what is the logic of it), the second, how do you convert that solution into something the programming language can execute (what is the syntax of it)?

It is possible to have a computer program that compiles and runs perfectly (correct syntax), but fails to correctly solve your problem, because the logic is incorrect. That is, you can get the second part right, but if the first part isn't also right, the whole fails.

Hence, initial student programs should be ones where either you don't worry about coding--you just solve the problem--or ones where you don't worry about how to solve the problem--you just code it.

For example, the (logical) solution to the problem of saying "Hello World" on the screen is trivial. In English it's:

Blank the screen (clean off whatever was there)
Show "hello world" on the screen
Make sure the screen doesn't go away because the program ends (or we won't see the message)

You can take that English description and code the program in dozens of different languages. Each one will be more or less different, but all will do the same thing. That's why "hello world" is usually the first program you do in a language, it is entirely a problem of language syntax, not of logic.

Example from one of the simplest programming languages, Windows command files (batch files):

CLS
echo Hello World
pause

Now, comparing the pseudo-code with the actual code, you can figure out what "CLS" means even if you don't know that it stands for "Clear Screen". You can figure out that "echo" means "Show (by default, on the screen) whatever comes after echo". You can guess that "pause" means "wait for the user to hit a key".

But if your problem is, "take a group of numbers and decide which ones are prime numbers", then you have to figure out how you can possibly do this at all, before you try to code it. If at the same time that you're trying to solve the logic problem, you try to figure out the program syntax, it becomes MUCH more difficult.

Object-oriented programming can throw kinks in the process, but most of the code in most programs is procedural, telling the computer to do this, do that, do the other thing. Any set of instructions, whether game rules, or product manuals, or software how-to's, amounts to a set of sequences of instructions, loops (repetitions until something particular happens or doesn't happen), and branches (decision points where the instructions go one way or another, sometimes from a choice of more than two). Since you can write English to reflect these three structures, you can write English pseudo-code for most any procedural problem. The example above is strictly a sequence. We could add a couple lines where the program would ask the user if he wanted to see "hello world" again or not:

Clear off the screen
Show "hello world" on the screen
Ask user if he wants to see more "hello worlds" on the screen
If user says yes, loop back to "Show", or else continue on to end
Make sure the screen doesn't go away because the program ends (or we won't see the message)

Now we have a branch (the IF) and the potential for a loop (going back to the "show"). Note the loop doesn't go all the way back to the start, or else the screen would be cleared again.

In fact this is not possible to do in Batch files (which are very, very simple), because there's no way to get user input within the program! (unless you use other programs for that purpose). But any "real" programming language can do it.



Here's an analogy. If you "kinda" know a second language, it is much easier to listen to (or read) that language and figure out what it means, than it is to take a meaning and turn it into that spoken (or written) language. In computer programming terms, in the first case, you're only worrying about the syntax; in the second you're worrying about both the logic and the syntax.

So, if you know some Spanish and you're trying to talk with a Spaniard who knows some English, you should speak English, and he should speak Spanish. You'll find it much easier to understand the Spanish you hear than to make it up and speak it, because you're not worrying about the creation, about solving the problem of what to say; he'll do much better sorting out your English and not worrying about how he's saying what he's saying, because he'll be using his native language.

By using pseudo-code you separate your "big mess" into two problems that you solve one after the other. It's much easier.

So, you've all heard (I hope) that the longer you take to plan a program, the less time it takes to code it. Pseudo-code is a principle tool when you're writing simple, short programs. (Longer ones require much more elaborate planning, such as systems analysis.)


This is why I advocate not teaching any one language to "novices", instead concentrating on the logic needed to solve problems with computer languages.