🚀 go-pugleaf

In article <17581@rpp386.cactus.org>,ntwoody@rpp386.cactus.org (Woodrow Baker) writes:
   > [I wrote:]
   > It's kind of like Forth in this respect--writing
   > code to handle single operations is fine, but I wouldn't want to write a
   > large application in it, even though it could be done.
   
   There have been some mighty large and powerful systems written in FORTH.
   because of it's extensibility, which it shares with PS, you can literaly
   build layer upon layer, until you can write an entire GL package with just
   1 screen of code.

As I said, you can certainly do it, I just wouldn't want to.  I mean, people
have written airline reservations system in APL, too.  I wasn't asking for
an existence proof :-).

   It seems that most people are unwilling to look at PS as anything other than
   a fancy printer controler command set.

Well, I look at it as a quite nice two-dimensional imaging language.  It
does an extremely good job of making the physical characteristics of the
imaging medium irrelevant to the task of describing the image itself.

Now, it is a lot like Lisp in being a ball of mud language (i.e., whatever
you add to a ball of mud, it's still a ball of mud), principally because
it has a very simple syntax balanced by often complex semantics.  Sun, for
example, has added some marvelous extensions for event handling and
lightweight processes, as well as multiple imaging surfaces (called
"canvases") and object-oriented method dispatching (which will also work
just fine in vanilla PostScript).

   I challenge you to pinpoint *ANY* major deficiency of PS for 
   general purpose programming.

- Named and lexically scoped local variables and parameters.  These can
  be simulated by using anonymous dictionaries that are patched into
  executable arrays, but this is a hack.

- A more sophisticated model of memory management.  A garbage-collecting
  storage management subsystem would make it much easier to implement
  complex data structures using dictionaries (a la NeWS) and to use
  persistent data structures in general.  'save' and 'restore' work
  great for throwaway code, or code that is executed on the fly (as most
  PostScript code is), but it suffers when you are using more persistent
  data structures, especially if they can change in size.

  To take a concrete example, I would find it much easier and more pleasant
  to write a B*-tree manipulation package in C or Lisp than I would in
  PostScript.  The 'right' way to write something in PostScript that used
  a database would be to add primitives to the interpreter I was using to
  do the low-level memory and file management.

- A more sophisticated I/O model.  Things like random access to file
  contents become important for general purpose programming.  The file
  system primitives provided with PostScript so far are designed for
  storing hunks of PostScript code (be they fonts or whatever), and they
  are pretty good at it, but sometimes you need more than simple text
  streams.

   There is no reason, other than predjudice,
   that one could not implement say a mailing list manager, using the hard
   disk, and generating forms and labels within the printer.

There is no reason that one *could* not, but there are many reasons why
one *would* not, not the least of which is that since you probably are
using a computer of some sort to give the printer commands, you may as
well use it for what it's good at.

Drawing labels and forms is quite appropriate for PostScript.  Database
management, however possible in a theoretical sense, is not, given
the current set of primitives that are defined as "PostScript."

The fact that many languages are Turing-equivalent does not mean that
they are equally suited for any given task :-).  Imagine describing
pages in assembler, for example...