Glenn Reid: That's an interesting question. There are several answers, I think. First, what the world came to know as PostScript was not in fact the first generation of the language. It took form as JaM (for John and Martin) when John Warnock was working with Martin Newell, then went through some more revisions as Interpress at Xerox's Palo Alto Research Center, and they rewrote it again as PostScript.

It was mature, well thought-out, and complete when it first shipped. It was intentionally designed to handle arbitrarily complex documents, rather than being restricted by memory or language limitations. This has proved incredibly far-sighted, as extremely complex pages have of course been built that no doubt have exceeded the original expectations of the designers.

PostScript has evolved and had revisions and changes, but the changes mostly are for convenience ("rectfill"), advances in color technology ("setcolorspace"), speed, or specific printer control ("setpagedevice"). None of these enhancements are required for most pages. In fact, there are still compelling reasons to write Level-1 compatible page descriptions, which are ultimately portable. I rarely reach for Level 2 or Level 3 operators unless there's a compelling reason to use them.

A second answer is that Java was not really finished when it was released, so there has been a great deal of work to do. As a language it was fairly complete at first release, but Java is not just a programming language; it is a "platform", and is only useful when large chunks of operating system software are provided as libraries and toolkits.

This work is still ongoing. Put another way, the "C" language has not changed much since it was invented, but you can't do much with "C" without interacting with the OS toolboxes, whether on Macintosh, Windows, or UNIX. Java was released before these sub-systems were mature (or even begun, in many cases). The language itself has not changed much, but the sub-systems are still changing wildly. With PostScript, the sub-systems were there from the beginning (file operations, for example), although substantial extensions were made for Display PostScript/Level 2.

Glenn Reid: The most common one that comes to mind, which in fact motivated an entire chapter in the book ("Trusting the Stack") is that programmers typically think in terms of 'variables'. There are no variables in PostScript. All operations are performed on objects on the operand stack. You can store something in a dictionary with a name and pretend that it's a variable, but when you "use" the variable, what you're really doing is pulling it out of the dictionary and putting it back on the operand stack where it started out.

This is an obvious inefficiency, and good PostScript programmers don't feel a need to make everything into a variable. It is, of course, often desirable and even necessary to give intermediate results names and store them in a dictionary so you can keep track of what you're doing, since it can be challenging to follow stack manipulations.

But it is amazing how many procedures you see which take several parameters on the stack, take them off the stack and put them into variables, then immediately pass those 'variables' to a PostScript operator, which of course puts them right back on the stack where they started. If the 'variable' is only used once, there's little point in doing that. After a while, when you start Thinking in PostScript, you set up your procedures to naturally use the objects directly from the operand stack as they are passed in.

Glenn Reid: Well, PostScript is a programming language, and PDF is not. They share the same Imaging Model, which means that you describe pages using the same mechanisms, coordinate systems, colors, and even data structures like paths and text and bitmaps. PDF is interpreted, but it is not executed in the strict sense.

You cannot have a loop in PDF, for example. Some people see this as a good thing, perhaps including me. What Acrobat Distiller does is to actually execute the PostScript program (which is the only way to truly determine what it does) but instead of reducing each painting operation to a bitmap, it preserves the higher-level representation of the shape or object or text and writes out an equivalent bit of PDF into the output file as it goes along.

This means that it "distills" the PostScript program down to just its essence: the operations that actually paint on the paper. An example of this might be a loop in PostScript that goes around 30 times, each time moving slightly down the page and drawing a line. In PostScript this might be expressed something like this:

35 600 moveto
1 1 30 { 400 0 rlineto -400 10 rmoveto } for
stroke

In the resulting PDF file, the loop itself would be gone, replaced by just the line-drawing operations. However, since the power of executing a loop is lost, you would now have 30 line-drawing instructions. In the business, we call this "unrolling" a loop.

Glenn Reid: Sort of. Mostly you need to understand the imaging model, which is somewhat complicated. You certainly don't need to understand the ins and outs of how a PostScript program executes, the stack and procedures and all that. But you need to understand what a path is, how text is drawn, what an image is, and how the three fit together into a page description.

Glenn Reid: It doesn't relate at all, which is sort of the point. People have different motivations for programming. Mine is largely creative: I like to design and build things, and programming languages are the ultimate building materials. There are no issues like sagging or breakage or dry rot or fatigue. A program either works or it doesn't. And you can make a perfect copy of your program before you start experimenting, and come back to it if your experiment didn't work.

What I enjoy about woodworking is mostly the design and partly the execution. I don't work from plans, I design everything myself, even fairly complicated furniture and cabinets. That, for me, is the pleasure of it. But it's much more challenging than programming because you can ruin all of it with one mistake.

You have to really think ahead, do things in the right order, and there was never an adage more true than "measure twice, cut once, measure once, cut twice." And it's low-tech, which I find appealing at the end of the day. No monitors, keyboards, or modems. I admit to using woodworking machinery, but if the power goes out, there's still a lot I can do.

Glenn Reid: Those are very different questions! I don't know much about Acrobat 4.0. I'll learn it when I need it, like everything else. But I'm sure it's full of good stuff. I use PDF for lots of things and truly believe it is great technology. It is ironclad in its platform independence, and it is often the simplest solution to the gnarly real-world problems of how to get a document to someone you don't know. Some people choose Microsoft Word for this task, figuring that the recipient will own a copy of Word. The rest of us use PDF.