🚀 go-pugleaf

In article <1690@intercon.com>, amanda@intercon.com (Amanda Walker) writes:
> In article <17581@rpp386.cactus.org>,ntwoody@rpp386.cactus.org (Woodrow Baker) writes:
> 
> 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.

true enough.  some times to irrelevant.

> 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
I suppose that you would classify APL as a mud-ball language as well.
Extensible langues (of which APL is not) could fall into that catagory.
I'm sure the Lisp people are gonna love you.
u
>    I challenge you to pinpoint *ANY* major deficiency of PS for 
>    general purpose programming.
> 
> - Named and lexically scoped local variables and parameters.  These can
> 
> - A more sophisticated model of memory management.  A garbage-collecting
>   storage management subsystem would make it much easier to implement
> 
> 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.

That is another oversight in the design of the language.
 
> - A more sophisticated I/O model.  Things like random access to file
>   contents become important for general purpose programming.  The file
> 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.

Why tie up your computer doing something that the printer is perfectly
capable of doing.  I agree the file handleing does lack a LOT, but it is
not unusable.
g
> 
> 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...

I can, because I have done it.  Everyone who has done any kind of screen
graphics package has done it either in assemlber, or in 'C' or perhaps
some other non-PS language.  One of the first programs I ever wrote was
a cassete label printing program in assembler.  It did shadowprinting,
bolding, underlining, etc, and used a 4800 baud JPC interface (it was
a SWTP 6800 system with 4k of ram) for a cassette based file system.
It does not perhaps sound like describing a page, but it essentialy was
is some sense.  It was neither pretty, nor easy, so I certainly.

You have definitly hit the problem areas of postscript.  These are
definitly deficiencies, but with the exception of the I/O primatives,
can be gotten around.  I think that "hacks" are just fine, if they accomplish
their desired end.  As long as they are well documented.

Cheers
Woody
s