Cannonballs! Part 5.2


by Robert Cailliau

The objects and their handlers

If we do not count the empty lines, the comment lines and the on-end lines of the handlers, then there are only 43 lines of Transcript language!

The objects and their scripts are like this:

I have shown a light grey rectangle for the mainstack and a darker grey rectangle for the only card on which all our objects sit. Of course in reality you only see the objects and not the grey rectangles.

Note this:

1. The two scrollbars and the button handle events: things you do to them.
   
2. The two objects we play with (the barrel and the ball) do not handle events.
   
3. The barrel is asked something about itself (the location of its nozzle).
   
4. The ball is told to do something (fly until it hits the grass).

If you think about it for a while: that's probably what we should expect!

Yes, they did: we spent a great deal of time understanding the problem. We had to learn how to move objects, the laws of motion and how to simulate physics. Once we understood all that, it was easy to write the program.

What do we mean by "writing the program"?
In the old days "writing a program" literally came down to that: starting at the top of a white sheet of paper and writing lines of code until the end of the program. Programmers were usually mathematicians, physicists or engineers. They already understood the problem and its solution, they just needed the exact numbers that came out of the calculations. Programs started from a few data, did a lot of calculations and came up with a few numbers as answers that they printed out.

There was no interaction between the programmer and the computer. I wrote my first programs without even seeing the computer, let alone touch its keyboard! I typed my code on the keyboards of card punches, outside the computer room:

(courtesy US Government and Wikipedia)

Operators took the punched cards and fed them into the computer via a card reader. Card readers looked like this:

(courtesy ibm1130.org)

The computer itself was another large box, even bigger than the card reader! It was 1968, the machine was an IBM 360/30 with 64k of memory. If the program worked, the operators then gave me a sheet of printed stuff back. The process usually took a day. I was lucky if I got answers back in the evening when I had handed my program to the operators in the morning. And very often there was an error in the program and I got no results back.

Here is a photo of a 360/30 like the one I used:

(Photo Courtesy of International Business Machines Corporation copyright (1964)
©International Business Machines Corporation)

You can see the central unit ("the computer") at the left, with a table and a typewriter in front of its control panel. The typewriter and control panel were called "the console". In the back are magnetic tape drives. Just in front of the tape drives you can see a card reader-punch. And in front of that again are two hard disc drives, with the discs visible. The cables connecting the discs and tapes to the computer ran under the floor. Computer rooms always had raised floors and removable tiles to access the cabling.

I said the machine had 64kB of memory: the black and white photograph above takes 22kB so it would have taken up more than 1/3 of the memory! This single web page would have exceeded the memory space. Of course there was far more space on the discs: about 7MB (a 7megapixel digital camera needs about that per photo in high quality mode).

Yet it was just as difficult or easy to program that machine as it is to program the machines of today.

When computers became cheaper, smaller, faster and more interactive, the troubles started: no longer were we happy with some numbers as "output", we wanted to make the machine help us think about the problems and present solutions in graphic form.

Today, using object-oriented programming, we no longer "write a program" even if we still use that phrase. What we have done with the cannonball program was to put together a small world and tell each object how to handle various events.
What a program is today

Each handler is equivalent to a program of the old days. The entire Cannon.rev is an application of the computer more than a program.

What is left: "documenting the program"
I have talked a bit about the past and how things were then. What about the future? You have made the Cannon.rev program and probably kept it somewhere. I guess you will keep it for a while, maybe for a long time.

Maybe in a year or two you will need to write something similar. You may want to look at how you did things in the Cannon.rev program, open it up again and try to understand it. But will you be able to understand it or will you have forgotten?

We have not written any clarifications, and that's the last piece of work we're going to do in the next tutorial.