🚀 go-pugleaf

In article <17601@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker)
writes in response to my article <1690@intercon.com>:
> > [PostScript]
> > 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.

NO!! [there, now I feel better :-)].  This device independence is one of the
biggest strength of PostScript.  If you absolutely need to "get around"
one of the principal design features of PostScript, then maybe you should
be using another kind of printer.

> I suppose that you would classify APL as a mud-ball language as well.

No, not particularly.  Change anything, and it's not APL any more...  More
like a "diamond" language.  The main characteristic of a ball-of-mud
languages is that they are syntax-poor and semantics-rich (relatively
speaking).

> I'm sure the Lisp people are gonna love you.

Hey, I *am* a Lisp people :-).  I take that as a compliment.

> > 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.

To paraphrase Monty Python, "The *language* don't enter into it."  My approach
would probably be to recompile the interpreter, since I wouldn't be running my
DBMS on my printer :-).  These extensions would be outside the PostScript
language per se just as much as the color separation conventions or NeWS's
event handling are.

> Why tie up your computer doing something that the printer is perfectly
> capable of doing.

Why tie up your printer doing something that the computer is perectly
capable of doing?  I don't know about you, but my computers are useful
for more things than being PostScript terminals...

> I agree the file handleing does lack a LOT, but it is
> not unusable.

You did ask for deficiencies, dear, not things that were completely
unusable :-).  We've already established than you *can* write damn near
anything in PostScript if you really want to...  You'd probably have a
lot of fun with NeWS, for example.

> > Imagine describing
> > pages in assembler, for example...
> 
> I can, because I have done it.

So have I, but I tend not to do it these days, because there are better tools
for the job available.

> 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 won't argue with that.

> I think that "hacks" are just fine, if they accomplish
> their desired end.  As long as they are well documented.

Sigh.  Woody, if they were documented, they'd be features, not hacks :-).
Complaining that what Adobe documents as "PostScript" isn't enough for
what you want to do (or how you think is the best way to do it) is silly.
It's like buying a Corvette and complaining that it doesn't have enough
leg room in the back seat.  However true it may be, it's more of a problem
with how you are trying to use it as with the manufacturer's design.

Maybe we should agree to disagree.  I agree with whoever said that this
kind of fla... er, discussion is more approriate to comp.laser-printers
than comp.lang.postscript.

Getting a little tired of this,

Amanda Walker
Speaker to PostScript
InterCon Systems Corporation
--