lect01a
a first program

computing vs. programming

Have you computed before? (Have you computed things that weren't numeric?) You certainly have!

adding two 10-digit numbers;
Buying this class's textbook by going to amazon's website.
Calculating how much paint is needed for the walls of this particular room, which is 25′×20′×10′.
Deciding whether or not to shout out “no deal, Howie Mandel!”, while watching Deal or No Deal.

These are all examples of computing — running a program. You followed a set of instructions (a program) to do each of these tasks.

Have you programmed before? (Have you programmed without using a computer?) Yes:

explaining to somebody else, how to add /any/ two 10-digit numbers.
explaining to your mom, how to order any book she wants, from amazon.
calculating how much paint is needed for the walls of /any/ room, given its length, width, and height in feet.
You got onto _Deal or No Deal_, but you have a big ITEC120 homework to finish. You tell your friend how to play for you. (perhaps: “keep playing until the banker's offer is at least $50,000” or “Never take the bankers offer while there are two prizes which are higher than the offer; otherwise do take it”.) (A set of instructions for playing a game is called a strategy.)

A computation is taking a general set of instructions for a task, and applying it to a specific situation (instance) of the task.

We call the specific situation the input argument(s) (for example, a room's measurements of 25′ × 20′ × 10′, or the specific title “Fall and Rise of the Roman Empire”). You've been computing since kindergarten.

A program is a general set of instructions for some task which can be applied to any specific instance of the task.

A computation solves one problem — but a program solves an infinite family of problems! Programs are more complicated than computations, because they're phrased in terms of parameters (or variables): the room-dimensions l, h, w, or a book-name title_book. This difference between a specific instance and the general, abstract case is a powerful concept, but more difficult: humans can't really make that distinction until around age 13 or so (which is why algebra isn't taught before that age: the idea of working with x and y instead of specific numbers is an abstraction).

In this class we'll learn programming, which is bit like algebra except that instead of working with numbers, it's been enriched to talk about any information: book-names, game-show boards, etc.. We'll happen to write our programs in a language called Java, which is nice because it lets the (boring, repetitive) computation side of things be carried out by a machine.

A first program

You are a rocket scientist. You have been fired by a special effects firm, to help make the first scene of their awesome upcoming UFO movie: They want to show the UFO dramatically rising from the secret UFO base. They can certainly making cool pictures, but they want to ask you where to draw the UFO on the screen.

Some domain-specific knowledge about movies: A movie is a series of still frames, projected rapidly. Each frame of the movie is created separately. The special effects folk will ask you questions like “where should the UFO be drawn, on frame 43?” and “where should the UFO be drawn, on frame 17?” You answer should be the y-coordinate of the UFO (it's altitude).

Zero seconds into the move -- at frame #0 -- the UFO should be sitting right on top the secret base. (You ask, and find out that the secret base is 102 pixels high).

Test cases

Where should the UFO be drawn at…
frame #0?
frame #1?
frame #2?
frame #3?
frame #17?
frame #100?

the general solution, programmed in arithmetic

In arithmetic, we'd write this as something like: h(x) = x+102 where h (for “height”) is the function, and x represents the general case -- x can stand for whatever number is being asked about (0, 3, 17, whatever). We say that x is a parameter.

Note how the test cases correspond to individual computations; the general case (involving x) is programming.

the general solution, programmed in Java

we'll use more descriptive names than “h” and “x”:
ufoHeightAt( frameNum )
we include the arithmetic's “x+102” (using our new parameter name):
ufoHeightAt( frameNum ) frameNum + 102
What's missing, from the arithmetic version? An equal-sign. Java doesn't use an equal sign; instead it uses a special keyword return:
ufoHeightAt( frameNum ) return frameNum + 102
We now have everything which had been present in the original arithmetic. However, Java still requires some extra punctuation:
ufoHeightAt( frameNum ) { return frameNum + 102; }
Finally, Java wants one more piece of information: the type of information being handled. (In arithmetic, everything used numbers, but in programming we'll extend that idea to text, true/false values, as well as customized bundles of other data.) In this case, the frameNum is an integer (whole number -- not a fraction),
ufoHeightAt( int frameNum ) { return frameNum + 102; }
and moreover the answer we return is also an integer:
int ufoHeightAt( int frameNum ) { return frameNum + 102; }
We say “the function's parameter type is int, and in this case its return type is also int”. In math classes, sometimes this is also written as “f : N → N”.

(We'll see other types of data in upcoming lessons: double for numbers with a decimal-point, boolean for true/false values, and String for text.)

We now have the Java version of our arithmetic program!

Running our program

Okay, now that we have the general program, let's use it to compute some specific cases: we can call the RocketScientist function ufoHeightAt directly, and also look at clips from the FXStudio. For each frame it renders, the FXStudio asks its RocketScientist about ufoHeightAt for that frame-number.

Whoops, what's wrong?! We'll debug this next lecture. In lab01a—Making Objects with BlueJ, we'll see how to call functions.

(Here is the FXStudio's jar file, and directions for downloading a jar file into BlueJ).

Reflecting on the process

In writing ufoHeightAt, we started by computing some sample cases by hand, before writing the general-case program. This approach wasn't accidental:

The Fourth ¹ Law of Programming
Before writing a program, first compute some test cases by hand.

There are two reasons for this law:

It provides a way to test our program. (Yes, the computer made sure our program was sensical, but it can't tell if we made some mistake like accidentally typing * instead of +.)
More importantly, computing some specific cases by hand helped us figure out exactly how to approach the problem.

Clearly, it's easier to do a specific calculation than write a general program for the same task. If you ever find yourself at a loss as to how start writing a program, you might well have forgotten to do some specific cases first. And if you have trouble with deciding how to compute a specific case, then you shouldn't be skipping to the harder problem of solving the general case!

¹Fear not -- we'll encounter the preceding four laws over the next few weeks. ↩

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

©2007, Ian Barland, Radford University
Last modified 2007.Aug.27 (Mon) Please mail any suggestions
(incl. typos, broken links)
to iba�rlandrad�ford.edu

lect01aa first program