I recently got the Postscript Red Book (the reference manual) as a gift from a good friend. He probably couldn't think of any reason to keep it. Postscript has found its niche in the printer world and has long since faded from the computing mainstream. It once was the API for displaying things on screen on NeXTstep in the form of Display Postscript and it was a fairly widespread 2D vector graphic file format in the form of EPS.
This all made me think back to an experiment with my wife and a possible new use for a language like Postscript (My friends and coworkers will love this blog entry. They know I'm a Postscript aficionado and their worst suspicions about this alleged PS fixation will be confirmed with this entry.) About a year ago my wife wanted to learn a little programming. She is a graphic and web designer, knows her tools of the trade like Photoshop, Illustrator, Dreamweaver, Flash and the like. But since these things are becoming fairly scriptable with Javascript and Actionscript she wanted to start writing little programs.
This presented me with the task of how to explain to an absolute beginner what programming is all about. Believe it or not, after a few false starts with other languages I chose Postscript as the teaching language. Ok, stay with me and hear me out, it's not as crazy as it sounds.
Here's a rough outline of the steps involved:
In the first step we simplify the available computing model significantly. We get rid of almost all operators and operands and only keep literal numbers and arithmetic operators. Our student is then asked to play a game: the student becomes a computer and needs to execute the programs we write. We have to use non-programming terms when describing the computing model the student will pretend to be. Thus the rules of the game are
- the program is a list of words
- the student will read the list from left to right doing something after reading each word:
- if the word is a number set it aside on a pile of numbers on top of the numbers already seen
- if the word is not a number it is an instruction that involves taking two numbers from the top of the pile, doing the arithmetic operation mentioned by the word with the two numbers and throwing the result back on top of the pile.
- when the last word is read from the list the number on top of the pile is the result of the game
This is all done with pencil and paper or even better with little scraps of paper with numbers or arithmetic operations written on them. We designate a place on our desk as the pile where our student can start stacking up the numbers. We provide empty scraps of paper on which the student can write results to throw them on the pile.
We then write a few programs, in the beginning fairly short ones, and let the student execute them. We gradually increase the length of the programs and let the student get comfortable with the game.
In the next step we reverse the roles. Now we are the computer executing programs written by the student. Notice the change: in the first step the student only had to follow the rules of the game, now he needs to think how to make us do what he wants under the same rules of the game. We can start the game with a few numbers already on the pile and the task of adding the two top ones, subtracting the result from the one below etc. Our student is writing programs without even realizing it, we haven't departed from the comfortable game world, there's no talk about variables, statements, syntax, types etc., things that overwhelm beginners.
The next step enriches our game a little. First we introduce new instructions, this time instructions that change the order in our pile of numbers (let's call it out as stack from now on). We can use the simple stack manipulation instructions like dup, exch, pop, copy, count and more complicated ones like roll. We play the same game first with the student as the computer so that he gets comfortable with the new instructions and what they mean and do, and then with us as the computer executing programs the student writes. The desired end results need to be clearly defined so the student can write programs that achieve these results after giving them to us for execution.
We can continue this game, gradually enriching it. First we can introduce an additional literal: strings, i.e. pieces of text. Strings are like numbers that when read are put onto the stack and then we can introduce instructions that act on strings. This is a useful addition because for one it illustrates the need to resolve ambiguity. How are strings distinguished from instructions in the list of words? We as the dumb computer program executors cannot do it without an additional rule that says that strings are enclosed by round braces and instructions are not. The round braces are not part of the string but only help to detect them in the list of program words. In addition to that the introduction of strings makes stacks more interesting. The rules of the game need to clarify that it is not allowed to add a number and a string etc. Having two types of literal objects makes the game more interesting and the problems the student needs to solve with the programs he writes more challenging (example: initially the stack has a number and a string, write a program that ends with the stack having the sum of the length of the string added to the initial number on top of the stack).
We play this game until the student is absolutely comfortable solving problems in it. The advantage here is that we chose a stack-based language with very easy concepts and very easy syntax. We also can play with it using pencil and paper which eliminates all the upfront housekeeping noise like: start the interpreter, write this into a file, point the interpreter to the file, specify these file paths etc. With us pretending to be the computer we can give much more human error messages and react much more subtle to our student than a silicone computer would ever do.
The next step is dictionaries and literals that are referenced by name with the literal itself stored in the dictionary. Lots of examples and practice again, first with the student as the computer and then with the student writing programs solving little problems involving these new concepts.
We continue with control flow, first the ifelse. Branching is important and needs to be practiced a lot. New literals, the booleans are needed here too.
Once we introduce loops it gets really fun. If our student gets comfortable we can even start going to a real computer, use a postscript interpreter and introduce some instructions that actually draw on screen. This is where our student is completely hooked and we can let him start to play on his own and write his own programs.
We can also start associating back these concepts to the actual target language the student wanted to learn like Javascript. With examples he already knows and understands in Postscript we explain terms like syntax, flow, branching, loops and literals etc basically the elements of a programming language. We then show what those are in say Javascript.
And finally we give the student a good introductory Javascript tutorial book and retreat exhausted into the background...
If you dare, take a member of your family on this discovery trip over the Holidays, a member who's a complete rookie but always wondered what you do in your profession. Oh, and in case you wonder, yes, our marriage survived the experiment.
