From the author of

From the author of

On Learning New Languages: Windows, an “Object” Lesson

One of my first jobs for Microsoft in 1986 was supporting Windows 1.0 development over the phone. We were given a month or two of training, which amounted mainly to plowing alone through the much despised Windows 1.0 Development Kit (SDK) documentation.

Then we were pretty much on our own, expected to answer the challenging questions that would come in on resource handles, graphic contexts, and the low-level details of DLL files. It was the most nightmarish experience of my professional life.

Part of the problem is that any Graphical User Interface system (GUI) tends to be notoriously difficult to learn unless you adopt a programmer-friendly layer that hides some of the details. “Raw GUI” tends to be challenging for those who would learn it as well as those who would attempt to teach it.

But much of the problem lay with the documentation distributed with the Windows 1.0 SDK. Although well intentioned and informative in its way, this documentation suffered from a flaw common to many training programs and books. It took a kitchen sink approach by starting with an application that demonstrated a little bit of everything you could possibly do with a Windows app. The result was to leave the reader with eyes glazed over and head spinning.

It’s understandable why so many instructors and authors take the kitchen sink approach. The author is proud of his or her knowledge and wants to make sure you know that they know all the information, and they want to display their expertise from the beginning. So they write “introductory” applications with an eye to showing off what great programmers they are.

But people don’t learn a language that way. Imagine you have never spoken a word of Japanese, and you go to your first class in the new language. How hopeless would you feel if the teacher started with a sophisticated essay written in the foreign language? Or how would you feel if the first sentences you were taught were at the PhD level?

Human beings do not learn that way. In the case of a natural (or rather, human) language, your first utterances are going to be the equivalent of “Hello,” “Goodbye,” “Thank you,” and “Please.” Only gradually do you work up to being able to write essays.

K&R & Hello, World

So, to begin learning a language, you should start by making sure you can write and build a simple program that says Hello. Then you can move onto progressively more complex programs.

The classic, best known textbook for learning C programming is probably The C Programming Language by Brian Kernighan and Dennis Ritchie. This book is written for a well informed audience comfortable with concepts such as programs, functions, data types, and memory addresses. Some students, unless they already have a programming background, find this book a little rough going at first.

And yet Kernighan and Ritchie (“K&R”) got one thing supremely right. Before you do anything else in a new language, you should verify you can at least print a simple message — that is, say “Hello” to the world. And so they started with one of the most famous of all programs, which in early C looks like this:

#include <stdio.h>
main() {
printf("Hello, world!\n");
}

In contemporary dialects of C++, this program looks a little different, but is similar:

#include <iostream>
int main() {
cout << "Hello, world! " << endl;
}

Such a program does nothing beyond printing a simple message, terminated with a newline, but it’s important to make sure you can do this much before trying anything more elaborate.

In the case of BASICA, such a program is trivial indeed, which is why it was the hobbyist’s language of choice in the 1970s and 1980s:

PRINT "HELLO, WORLD!"

To some programmers, these programs might seem too trivial to bother with, but that’s because they already know the language! Getting just this much to work means many things have to go right. You have to employ the right grammar — either including the necessary commas and semi-colons or (in the case of BASICA) not including them. Then you have to build, link, and run the program using all the correct tools.

In the case of a complex programming system, such as a GUI with no simplifying layers, just displaying “Hello, world!” may itself be a considerable task.

What Do You Do After You Say Hello?

Of course, if all you can do is say “Hello,” you hardly know a language at all. What do you do next?

Many textbooks (the less successful ones, in my opinion) suggest you sit down and memorize all the keywords and learn all the grammar by staring for hours at syntax diagrams. But I’ve always found that approach to be a waste of time. You don’t learn German, for example, but staring at vocabulary lists. If you’re like 99% of the population, what you really need is a functional approach to learning a language.

After you say “Hello,” the most important tasks to master are basic input and output. Learning how to crunch data is important, too, but such operations are usually learned easily. Except for a few specialized languages such as assembly language and LISP, most modern languages use standard infix notation for arithmetic, with only a few variations. For example, the following works in Basic, C, C++, C#, and Java with almost no adjustments (mainly, you’d need to add a semi-colon at the end with the C family).

Fahrenheit = (Centigrade * 1.8) + 32.0

Before you write this statement, however, you’re usually going to have to declare simple variables. Therefore, your first applications, after “Hello, world,” should focus on the following tasks:

Declare simple variables of the correct type. (Usually floating-point and integer are both supported.)

Get input from the end user.

Crunch the numbers by performing some arithmetic operations.

Display the results.

If you can do just these four things, you are, in my view, already starting to do real programming. Of course, if you can only do these four things, you’re limited to pretty simple applications, such as converting Fahrenheit to Centigrade and vice-versa, which isn’t very exciting.

Decisions, Decisions…

The next step, therefore, is to start learning to use looping and decision-making statements, often referred to collectively as “control-flow structures.”

With the introduction of a few simple control structures, you can start programming in earnest. I suggest writing simple game programs that interact with the user. You can write these whether you are using a Graphical User Interface or a command-line interface.

For example, you can play a subtraction game in which the total starts at, say, seven, and the human player (that is, the end user) and the computer player take turns subtracting either 1 or 2 from the total. The winner is the player who first makes the total exactly equal to zero.

Such a program is going to look different depending on the language, but the pseudo-code for a correct implementation is shown below. You’ll need to figure out how to perform a Remainder or modulus operation. The heuristic (that is to say, strategy) of the computer player here is to try to always keep the total a multiple of 3. Eventually, then, 3 will be reached. Regardless of whether the human player subtracts 1 or 2, the computer player will then be able to make the total precisely 0, thereby winning the game.

While (True)
N = remainder from Total divided by 3
If N > 0 Then
Subtract N From Total
Else
Subtract 1 From Total
Inform user of the results
If Total is 0 Then print "I win" and exit
Prompt user for input: Enter 1 or 2
While (Input < 1 Or Input > 2)
Print error message
Re-prompt user for input
If Total = 0 Then print "You win" and exit

Another game program I recommend in my books is the “Guessing Game.” The computer randomly selects a number in a specified range and then lets the human player make successive guesses until he or she gets the correct answer. Each time, the computer reports whether the correct answer is higher, lower, or equal to the end user’s guess. Playing this game teaches the user about the logic of binary trees. To write such a program, of course, you’ll need to learn how to generate a random number.

Onward and Upward

Only at this point should you attempt to learn the more advanced techniques in a programming language. This includes the ability to pass data back and forth between multiple subroutines—also called “procedures,” “methods,” or “functions.”

Passing data back and forth between subroutines, in turn, brings up related subjects that—depending on the language—can be either simple or involved. These include:

pointers, the use of which is virtually required in C

pass by reference

the use of reference types, closely related to pass by reference

arrays

The last topic, arrays, leads us into the creation of complex data types. That, in turn, leads us to the C-word (classes) and the O-word (objects).

In the past, the topics of objects and classes were usually introduced as a very advanced topic; now the trend is to try to introduce these subjects from the very beginning of a textbook or course.

For some languages, notably Smalltalk and its variations, it’s necessary to understand object orientation from the very outset, because everything in the language works as some kind of object. In the case of C# and Java, it’s required that you use the “class” keyword to create anything at all.

But do you really need to understand classes to write a program that prints “Hello, world”? No. In the beginning, the class declaration is part of the boilerplate, so to speak, that you have to use (like the “main” keyword in C) in even the simplest program. I recommend that you investigate classes and objects more seriously than that only when you start writing an application that makes more extensive, practical use of them.

In the case of C#, you need to understand objects and references just to create any kind of array. Therefore, if you really want to understand classes, objects, and references in C#, write some applications that employ arrays—particularly control arrays.

Progressing to More Serious Applications

Despite what I said earlier, you can’t really feel that you know a language until you finally tackle a serious application—one that you’re very interested in or might even use for your own daily benefit.

One choice of serious app that I’d strongly recommend is John Horton Conway’s Game of Life. Although this is not exactly a practical application, it is intrinsically fascinating. It’s a computer simulation of living cells. It features a two-dimensional grid that every second or so (or whatever time interval you like) changes to display a new generation of cells. Some cells will die, others will live, and new ones will be born. To transition from one generation to another, each location on the grid obeys the following rules, in which neighbors include all cells (that is, populated grid locations) immediately up, down, right, left, or connected diagonally.

If a cell has fewer than two neighbors, it dies from starvation.

If a grid location has exactly two cells as neighbors, it maintains the status quo: if it is a populated grid location (that is, there is a cell there already) it remains populated; if it is an empty grid location, it remains remain empty.

If a grid location has exactly three cells as neighbors, there is a “birth” event. If the location is empty, it becomes populated. If the grid location is already populated, it remains populated.

If a cell has more than three neighbors that are populated, it dies from starvation.

The rules are simple enough, but implementing them involves significant work. You need to employ some mastery of decision making, loops, input, output (because you need a way to display each generation), and two-dimensional arrays. If you want to control the timing of the generations, you’ll also need some way to access the system clock.

The Game of Life provides another opportunity. If you want to save the state of generations, you can use this application to cut your teeth on disk-file operations—which usually have a different protocol, or set of functions, in each language. Mastering this last ability is important, because most useful applications involve the ability to load and save persistent information at some point.

In the final analysis, the way you learn a programming language is not so different from the way you learn a natural (or “human”) language. Very few people can learn a language by staring at and trying to memorize long lists of definitions or syntax diagrams. New language learning programs, such as Rosetta Stone, are built on this understanding: you learn a language by using it and interacting with the tutorial. In the beginning, that’s going to mean learning to say Hello.