[nibbula]

Although I admire and frequently agree with this blog, I think this article exhibits some common misconceptions about NeWS. NeWS had what amounted to uploadable toolkits, and therefore could and did have multiple toolkits. A client could decide how it wanted to separate processing between the client and server, which seems truly more flexible and allows for much more efficient communication. Also NeWS had threads which if done today would certainly use multiple processors. Clients could, but didn't have to, use a separate address space and language even. But the graphics API was so much better, it's ridiculous, and is basically the same as now in SVG, html canvas, and most other decent things.

The big drawbacks of NeWS in my opinion are not having an MIT license, and being quite difficult to implement well. Also PostScript isn't the nicest language to program in, which I say from years of programming in it. But it's far from the worst, and if one changed the to postfix syntax to prefix, it would be mostly a Lisp.

[kick]

What do you not like about PostScript? It's basically a worse Forth, which, when compared to most languages, is comparatively wonderful to write in.

[nibbula]

Writing bigger programs I struggled to understand what I wrote without comments on every line describing the stack. One could use more variables to make it easier to understand, but in the old days that would also make it less efficient. I would frequently have to reverse engineer my code.

Interestingly, object oriented PostScript would tend to help make your code seem more like prefix code, because it would be like more like "object method argument ... send" rather than "... arg arg function".

[triska]

How is PostScript a "worse Forth"? I find PostScript great fun to program in, and I think the type errors one gets from the system to indicate mistakes are a great help when writing PostScript code.

[dubya]

I remember that pre-1990, PostScript seemed like a miracle. "Computer Shopper" of all things, used to have a PostScript Guru column with all kinds of interesting stuff. All the computer I had access to was an Atari ST with GFA Basic, so really only the math and ideas translated, but it really was like seeing the future. Path-clipping in particular was mind-blowing.

It's partly archived online, and weirder than I remember! https://www.tinaja.com/glair01.shtml

[kick]

It's much higher level, chooses the worst bits of high-level languages to throw in, NeWS's spin of it was object-oriented which has since been shown to be a mistake, it's not as extensible, has too many stacks, introduces significant complexity for dubious benefit, so forth.

Of course, whether or not PostScript is like Forth at all is a matter of debate, some religiously disagree. I'm somewhere in the middle on that. Old flamewar topic:

http://wiki.c2.com/?ForthPostscriptRelationship

The syntax is also slightly less nice, which is relevant for their question, but less quantifiable.

[DonHopkins]

Object oriented programming has since been shown to be a mistake??! That's NeWS to me. Can you provide a citation please?

What do you mean that NeWS or PostScript classes are not extensible? The little "e" in NeWS stands for "extensible".

And what is the correct number of stacks, in your opinion?

Please quantify what you can, and provide examples and links to code, and citations of other people who agree with your personal opinions like the number of stacks a language is supposed to have, the meaning of extensibility, or that object oriented programming languages are a mistake.

[agumonkey]

> The little "e" in NeWS stands for "extensible".

But maybe that capital N is for Non .. (kidding obviously)

I've always been curious about NeWS but the web is quite short of demos about it (not helped by newspapers called Sun either). Do you know sites with videos about it ?

[DonHopkins]

Thanks for asking! ;) I've put up some old demos on youtube, and made illustrated transcriptions of some, and written some papers and articles. Sorry the compression is so terrible on some of the videos. Here are some links:

The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989

https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...

PSIBER Space Deck and Pseudo Scientific Visualizer Demo. Demo of the PseudoScientific Visualizer and NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.

https://www.youtube.com/watch?v=_fqCeuue5Ac

Pseudo Scientific Visualizer. Demo of the NeWS PseudoScientific Visualizer and the PSIBER Space Deck.

https://www.youtube.com/watch?v=GatM3s2S75Q

Mousee Demo. Demo of Mousee running in the NeWS Window System.

https://www.youtube.com/watch?v=PRP2QorRDUw

Ben Shneiderman introduces Pie Menus developed by Don Hopkins at UMD Human Computer Interaction Lab. University of Maryland Human Computer Interaction Lab Pie Menu Demos.

https://www.youtube.com/watch?v=kxkfqgAkgDc

Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser. By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. Published in Hypermedia, vol. 3, 2 (1991)101–117.

https://medium.com/@donhopkins/designing-to-facilitate-brows...

HCIL Demo - HyperTIES Browsing. Demo of NeWS based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab.

https://www.youtube.com/watch?v=fZi4gUjaGAM

HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS. Demo of UniPress Emacs based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab. Tabbed window management with pie menus.

https://www.youtube.com/watch?v=hhmU2B79EDU

Just the Pie Menus from All the Widgets. Pie menu demo excerpts from "All The Widgets" CHI'90 Special Issue #57 ACM SIGGRAPH Video Review, produced by and narrated by Brad Meyers.

https://www.youtube.com/watch?v=mOLS9I_tdKE

Precision Pie Demo.

https://www.youtube.com/watch?v=c0scs59va4c

Handy Pie Menu Demo.

https://www.youtube.com/watch?v=TuA_yylYwjM

How To Choose with Pie Menus. Early pie menu demo by Don Hopkins, on NeWS 1.0, running on a Sun 3 workstation. Featuring the World's Most Enormous Pie Menu, and Direct PacManipulation!

https://www.youtube.com/watch?v=MOJaY6Xu7ao

NeWS Tab Window Demo. Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0.

https://www.youtube.com/watch?v=tMcmQk-q0k4

SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS)). HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

HyperLook SimCity Demo Transcript. This is a transcript of a video taped demonstration of SimCity on HyperLook in NeWS.

https://medium.com/@donhopkins/hyperlook-simcity-demo-transc...

HyperLook Demo. Demonstration of SimCity running under the HyperLook user interface development system, based on NeWS PostScript, running on a SPARCstation 2. Includes a demonstration of editing HyperLook graphics and user interfaces, the HyperLook Cellular Automata Machine, and the HyperLook Happy Tool. Also shows The NeWS Toolkit applications PizzaTool and RasterRap. HyperLook developed by Arthur van Hoff and Don Hopkins at the Turing Institute. SimCity ported to Unix and HyperLook by Don Hopkins. HyperLook Cellular Automata Machine, Happy Tool, The NeWS Toolkit, PizzaTool and Raster Rap developed by Don Hopkins. Demonstration, transcript and close captioning by Don Hopkins. Camera and interview by Abbe Don. Taped at the San Francisco Exploratorium.

https://www.youtube.com/watch?v=avJnpDKHxPY

The Story of Sun Microsystems PizzaTool. How I accidentally ordered my first pizza over the internet.

https://medium.com/@donhopkins/the-story-of-sun-microsystems...

The X-Windows Disaster. This is Chapter 7 of the UNIX-HATERS Handbook. The X-Windows Disaster chapter was written by Don Hopkins.

https://medium.com/@donhopkins/the-x-windows-disaster-128d39...

[0x445442]

Yeah, I'd say GUI development is one of the places OOP really shines. I think a lot of the OOP was a mistake opinions come from its ubiquitous use in the enterprise, even in domains for which it was not well suited.

[nineteen999]

I would venture game development as well - UE4's actor and component model is a good example of this, it's a very flexible system that allows you to strike a good balance between inheritance and composition.

[arethuza]

I did a fair bit of PostScript development in NeWS/HyperNeWS and while I really liked PostScript I've never been able to get into Forth - I actually thought that PostScript was rather like the Common Lisp that the rest of the project used (one of the things I wrote for the project being the glue code in C to link the PostScript world of NeWS to Common Lisp - which is a nice mix of approaches to syntax!).

NB: It was particularly neat that Sun shipped a set of Adobe blue/green/red(?) books with OpenWindows.

[kick]

PostScript does take a lot from Lisp, too. And (kind of) Smalltalk. 'DonHopkins has posted a lot about it on here; I really love hearing him talk about it:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[arethuza]

I just found this article by Don about HyperNews and related stuff:

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

[protomyth]

PostScript is a much more advanced and easier to program language than Forth. Just how you can use def in all its forms makes a lot of things easier. Hand written PostScript code is very easy to read.

[DonHopkins]

In what way is PostScript worse than Forth? Please answer with specific details, and provide links to code if you can. I programmed a lot of Forth code before learning and moving on to programming a lot of PostScript code, so I've used each of them extensively, and much prefer PostScript, and I'm happy to show you why and explain by showing you code.

PostScript is much higher level than Forth, and a lot more like Lisp than Forth, and has much better data structures than Forth, like polymorphic arrays (that can be used as code), dictionaries (that can be used as objects), strings, floating point numbers, and NeWS "magic dictionaries" that can represent built-in objects like canvases, processes, events, fonts, etc.

Yet Forth doesn't even have dynamically allocated memory, although in a few pages of code you can implement it, but it's not standard and very few Forth libraries use it, and instead use the linear Forth dictionary memory (which is terribly limited and can't be freed without FORGETting everything defined after you allocated it):

https://donhopkins.com/home/archive/forth/alloc.f

PostScript is homoiconic. Like Lisp, PostScript code IS first class PostScript data, and you can pass functions around as first class objects and call them later.

https://en.wikipedia.org/wiki/Homoiconicity

PostScript lets you define local variables with names in dictionaries, and use stacks of those dictionaries as objects and classes, while Forth requires you to keep track of everything on the stack without giving it a name. Forth variables are effectively globals. The fact that PostScript is homoiconic means you can write PostScript functions that dynamically create and transform other PostScript functions, like Lisp macros.

In October 1986, before I ever used NeWS or learned of Owen Densmore's Smalltalk-like PostScript object system, I had just used PostScript on the LaserWriter and invented my own simple object system like Lisp Machine Flavors (which was quite easy and obvious) for drawing pie menus, I wrote the following to Mitch Bradley comparing Forth and PostScript. (Mitch was the Forth guru at Sun who developed ForthMacs / Sun Forth / CForth / Open Firmware / etc -- I worked with him at Sun on Forth as his summer intern, then later with James Gosling at Sun on NeWS as a full time employee):

https://github.com/MitchBradley

https://donhopkins.com/home/archive/forth/forth-postscript.t...

>After having programmed in PostScript for some time, how do you feel about its relation to Forth? Have your feelings about Forth changed any?

>They are somewhat different languages, suitable for different applications, but there is a lot of overlap, however. There are features and problems that each has that the other lacks. I have thought a lot about doing in PostScript some of the things one can do in Forth, as well as Lisp.

>In writing the code for the PieMenus on the Laser Writer, I had to come up with some way to make objects, not unlike flavors. It would also be interesting to make objects in the manner of <builds and does>. Objects are obviously implemented as dictionaries. Instance variables and messages are just bindings in the dictionary. The question is how do you build the dictionaries?

>You can have PostScript functions that build them by hand, or you can have it more data driven. (Not to say that PostScript functions aren't data. Weee!) But how do you represent the data? You want to specify defaults when creating a class, and values when instantiating objects.

>Should the creation of classes and objects be the same operation? (As with XLisp.) The required instance variable values could be taken as arguments when instantiating an object of some class, and the optional ones

>How about object instantiation consuming required values? right off the stack? How would inheritance work? By concatinating dictionaries, or by nesting them?

>It sure doesn't take much code to do this stuff. This is because PostScript has a very general set of building blocks for just such things.

PostScript makes it easy to efficiently implement a flexible dynamic object oriented programming system like Smalltalk's, with multiple inheritance, and prototype objects that you can dynamically promote both methods and instance variables from classes to instances. Tom Stambaugh described how Smalltalk inspired Owen Densmore's PostScript object oriented system in NeWS:

https://news.ycombinator.com/item?id=18696116

>It seems to me that Forth is to stacks what LispLanguage is to lists. Forth demonstrated the advantages of a stack-centric paradigm in which each pushed or popped item could be evaluated as an expression or a primitive. Postscript reflects the application of that paradigm to the world of typography, 2-d graphics, and page layout. My own recollection is that Postscript's primary contribution was the use of splines to describe character glyphs, allowing them to be effectively rendered at virtually any resolution desired. If anything, Postscript owes more to TexLanguage and DonaldKnuth than to Forth. I view the stack-based language paradigm as a convenient afterthought rather than a central organizing principle.

>I also think we should note the contribution that OwenDensmore, at Sun, made in demonstrating how to use Postscript dictionaries to create a dynamically-bound object-oriented runtime environment. This was the fundamental premise of the Sun window server that ultimately became the NetworkExtensibleWindowSystem. Owen and I discussed his "crazy" idea at a poolside table at the now-demolished Hyatt Palo Alto, on El Camino. I told him that it made sense to me, we scribbled furiously on napkins, and I helped him see how he might adopt some learnings from Smalltalk. It was one of those afternoons that could only have happened at that time in that place in that culture. -- TomStambaugh

>I've extracted Owen Densmore's paper from the news.tape.tar (marked PD), "Object Oriented programming in NeWS", and uploaded it:

https://ia802600.us.archive.org/5/items/pdfy-1U9Ry1_Qj0LPSR6...

Like Lisp or Scheme, you can easily write a metacircular PostScript evaluator in a few pages of PostScript:

https://news.ycombinator.com/item?id=21968842

>Also, here is a metacircular PostScript interpreter, ps.ps: a PostScript interpreter written in PostScript! Since PostScript is homoiconic and so much like Lisp, it was as easy as writing a metacircular Lisp interpreter (but quite different in how it works, since PostScript and Lisp have very different execution models).

https://www.donhopkins.com/home/code/ps.ps.txt

https://donhopkins.com/home/archive/psiber/cyber/ps.ps.reaso...

    Obvious Question:
      Why would anybody ever write a PostScript interpreter in PostScript?

    Possible Answers:
      To use as a debugging tool.
      To trace and single step through the execution of PostScript code.
      To serve as a basis for PostScript algorithm animation.
      To gain a deeper understanding of how PostScript works.
      To try out some ideas from Structure and Interpreteration.
      To experiment with extensions to the PostScript language.
      To demonstrate that PostScript isn't just for breakfast any more.
      To make PostScript run even slower (but thicker).
      To avoid programming in C (the portable assembly language of the 80's).
      To use to interpret its self.
      To have something nerdish to talk about at parties.

And you can use NeWS PostScript to implement a visual programming system and debugger to itself:

https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...

NeWS not only supported multiple loadable toolkits, but it had "packages" to keep them safely separated and modularized so clients could request whatever versions of whatever toolkits they needed, and the same code and data would be properly shared between all compatible clients. (See "findpackage" / "beginpackage" at the beginning of every X11/NeWS program, like this X11 window manager for NeWS implemented in PostScript:)

https://www.donhopkins.com/home/archive/NeWS/owm.ps.txt

In case you would rather program in a Lisp-like syntax than PostScript, David Singer and Rafael Bracho at Schlumberger wrote ListScript, a Lisp to PostScript compiler:

https://donhopkins.com/home/archive/NeWS/NeScheme.txt

>PostScript is often compared to Forth, but what it lacks in relation to Forth is a user-extensible compiler. You can write your own PostScript control structures and whatnot, like case and cond, to which you pass procedures as arguments on the stack, but the PostScript scanner is not smart -- but there is no preprocessing done to the PostScript text being read in, like the way immediate words in Forth can take control and manipulate the contents of the dictionary and stack while the text source is being read in and compiled, or like the way Lisp macros work. This is one of the things I would like to be able to do with something like LispScript.

And in case you are suffering from poor taste in programming languages, and you don't like Lisp but would rather program in a C- or Java-like syntax than PostScript, Arthur van Hoff at the Turing Institute wrote PdB, an object oriented C to PostScript compiler, which let you subclass PostScript classes in PdB, and also subclass PdB classes in PostScript:

https://news.ycombinator.com/item?id=21968842

>And later on around 1990-1993, Arthur van Hoff wrote PdB at the Turing Institute in Glasgow, an object oriented C to PostScript compiler called PdB (for Pure dead Brilliant), which is kind of like TypeScript, conceptually. We used PdB to develop HyperLook (Networked PostScript based HyperCard for NeWS), which I used to port SimCity to NeWS on Unix. (A few years after that, Arthur wrote the Java compiler in Java at Sun in 1995, and lot of other cool stuff since then!)

[DonHopkins]

Here is an example of making Lisp-like macros with PostScript, using a technique like "backquote", to compile PostScript code templates into more efficient drawing functions, and promote customized dynamically generated code into the instances (NeWS had a prototype based object system that made that possible).

This is a design document I wrote for Open Look Sliders for The NeWS Toolkit 2.0.

https://www.donhopkins.com/home/archive/NeWS/tnt-sliders-des...

* THE PROBLEM:

The tNt 1.0 slider implementation was a subclass of ClassDialControl, which was a subclass of ClassControl. It needed to be reimplemented, directly as a subclass of ClassCanvas (with ClassTarget mixed in), and had to be taught to play games with the services architecture, and brought in line with the controls architecture. All that hot air from the collapse of the ParentDictArray had to go somewhere, so the slider was graphically "puffed up" with a fake 3-D look. It is hoped that the result of this transfer of energy will result in a net decrease in size and increase in speed. To cope with the increase in complexity of drawing special effects, a form of inlining or macro expansion similar to "backquote" in lisp was used, to promote fast drawing procedures into slider instances.

* DESIGN CHOICES:

space/time tradeoffs The backquote technique speeds up drawing but takes up space. But the macro templates (defined as methods that are inlined and promoted) can still be executed even if they haven't been promoted. There is a small hit for executing "," which is defined as "/, {exec} def" (since it can't be defined as "/, /exec load def" because of autobind). And of course the templates are slower than the their inlined promoted expansions, because they're calculating the values each time instead of just pushing constants. Right now, the promotion happens upon /reshape, when the size is known and the layout can be calculated. Another space saving trade-off might be to only expand and promote the macros at the start of tracking, during which parts of the control must be frequently repainted, and unpromote it upon completion of tracking.

[DonHopkins]

Here's the PdB object oriented C to PostScript compiler and lots of other NeWS stuff:

https://github.com/IanDarwin/OpenLookCDROM/blob/master/NeWS/...

https://github.com/IanDarwin/OpenLookCDROM/tree/master/NeWS/...

https://github.com/IanDarwin/OpenLookCDROM/tree/master/NeWS

Also a paper by Arthur van Hoff about "Syntactic Extensions to PdB to Support TNT Classing Mechanisms":

https://www.donhopkins.com/home/archive/NeWS/PdB.txt

More LispScript stuff (compiling Lisp to PostScript):

https://www.donhopkins.com/home/archive/NeWS/NeScheme.txt

And to compare some window management tasks in Forth and PostScript:

X10 window manager in Forth:

https://www.donhopkins.com/home/code/fuwm-main.forth.txt

X11 window manager in PostScript:

https://www.donhopkins.com/home/archive/NeWS/owm.ps.txt

NeWS tabbed pie menu window manager in PostScript for TNT 2.2 (which "owm" could wrap around X-Windows):

https://www.donhopkins.com/home/archive/NeWS/tab-3.0.2.ps.tx...

NeWS Tab Window Demo: Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0.

https://www.youtube.com/watch?v=tMcmQk-q0k4

[gnufx]

Thanks for all this stuff, some of which I wish I'd been aware of at the time, like LispScript.

I don't remember the details, like how it was used, but I recall the metacircular evaluator in HyperNeWS (or do I mean HyperLook?) being called out as a (the?) major pain point in the system for speed of the interpreter.

[DonHopkins]

I wrote a metacircular evaluator, ps.ps, but I only used it in PSIBER for debugging (single stepping through code, which the normal PostScript interpreter didn't support directly, and also drawing visualizations of code execution). So the fact that it was slow wasn't really an issue, since it wasn't used in any speed critical situation.

https://www.donhopkins.com/home/code/ps.ps.txt

Nether GoodNeWS aka HyperNeWS aka HyperLook nor TNT (The NeWS Toolkit) used a metacircular evaluator themselves.

HyperLook could copy the image of windows to the clipboard as a PostScript drawing, but didn't need to use "PostScript capture" for that [below], because it represented drawings in its own format as a display list of PostScript data, that PostScript code interpreted to draw, and when you printed an image, it would just send a header with the drawing interpreter to the printer, followed by the drawing data and a call to the interpreter.

Maybe it was the speed of the structured drawing interpreter that people were complaining about. There is some overhead of course, but it's washed out by the fact that actually performing the drawing itself takes much more time than interpreting the data.

Or maybe you're thinking of "PostScript capture", which is effectively "partial evaluation" of arbitrary PostScript code, with respect to the imaging model (making paths, filling and stroking them, and rendering text)? You can efficiently implement PostScript capture without resorting to a metacircular evaluator, simply be redefining a few key operators like "fill", "stroke", "show", etc.

https://en.wikipedia.org/wiki/Partial_evaluation

PostScript capture is the technique of executing some arbitrary PostScript code that produces a drawing (which could be a traditional document in a PostScript file meant for the printer, or even a window system object like a menu), and capturing the drawing commands as another PostScript program, without any computation, conditionals, and loops. It would capture the effects of the drawing commands as another simple, flat PostScript program with all the conditionals and loops unwound (so a small recursive drawing procedure would produce an enormous flat drawing file, but most normal documents would be optimized to be smaller and even print faster), in the same global coordinate system, with unnecessary graphics state changes removed.

That's the essence of Adobe Acrobat's "Distiller", or Glenn Reid's "PostScript Distillery". I wrote distill.ps "in the spirit of Glenn Reid's Distillery" for PSIBER, and the NeWS Toolkit had its own /capture method built in, but they weren't actually used for much besides making a few illustrations.

https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...

>Printing Distilled PostScript

>The data structure displays (including those of the Pseudo Scientific Visualizer, described below) can be printed on a PostScript printer by capturing the drawing commands in a file.

>Glenn Reid’s “Distillery” program is a PostScript optimizer, that executes a page description, and (in most cases) produces another smaller, more efficient PostScript program, that prints the same image. [Reid, The Distillery] The trick is to redefine the path consuming operators, like fill, stroke, and show, so they write out the path in device space, and incremental changes to the graphics state. Even though the program that computes the display may be quite complicated, the distilled graphical output is very simple and low level, with all the loops unrolled.

>The NeWS distillery uses the same basic technique as Glenn Reid’s Distillery, but it is much simpler, does not optimize as much, and is not as complete.

Here's more about the metacircular interpreter and distilled PostScript:

https://news.ycombinator.com/item?id=13705664

>What you've described sounds exactly like a PostScript interpreter! You can easily write a metacircular PostScript interpreter in PostScript!

http://www.donhopkins.com/home/psiber/cyber/ps.ps.txt

>And here is a PostScript quine:

    {{[ exch /dup load /exec load ] cvx} dup exec}

>If you wanted to produce "safe" PostScript file for printing, that used a standard header file and didn't require a Turing complete printer with loops, conditionals, functions, etc, you could write a partial evaluator for PostScript that projects it against the stencil-paint imaging model, optimizes the graphics, and prints out another "safe" PostScript program using a standard header, with all the loops unrolled and conditionals evaluated and functions called and graphics in the same coordinate system. That would enable you to capture anything you draw on the screen, independent of the PostScript algorithmic procedures and classes and libraries and application required to draw it.

http://www.donhopkins.com/home/psiber/cyber/distill.ps.txt

>Glenn Reid, who also wrote books on PostScript like Thinking in PostScript, pioneered that idea in his "PostScript Language Distillery", which is the idea that grew into PDF.

http://donhopkins.com/home/archive/postscript/newerstill.ps....

Glenn tells me that the PostScript distillery was actually John Warnock's idea!

[fortran77]

Sir, this is an Olive Garden.