Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!adobe!heaven!heaven.woodside.ca.us
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: Diatribe
Message-ID: <489@heaven.woodside.ca.us>
Date: 5 May 91 17:54:20 GMT
References: <1991May5.003003.17184@neon.Stanford.EDU>
Sender: glenn@heaven.woodside.ca.us
Lines: 60

Tomas G. Rokicki writes

[diatribe omitted to save bandwidth]

Tom, you raise some good, undeniable points.  I won't argue with you.

However, I will point out that your description of what is wrong with
"bind" appears to have a slight oversimplification:

> But if the PostScript program that includes your file as a graphic has a
> definition for the name that is being bound, it is {\it that\/} definition
> that is `caught' by the bind---and no amount of redefinitions by the
> included graphic will `unbind' the name.  So the included graphic---and
> the entire document---fails.

The nit that I wanted to pick is that it's not "any" definition for the
name that's being bound.  The definition must refer directly to an
operator object for it to be `caught' by bind.  Other than that, you're
right.  See my other post for another perspective on this problem,
though.

As for the rest of the diatribe, although I agree with you, I actually
think that the problems are no worse than in most other areas of the
computer industry (compare versions and implementations of UNIX, for
example, or look at the "32-bit clean" nightmare on the Mac, soon to
be the "System 7.0" nightmare).  Any time a large number of people
participate in a portable solution, there are going to be misinterpretations
of the standard, differences in implementation, and all the other
little things that can go wrong when you can't test your stuff against
everybody else's stuff.

Imagine two carpenters building a door.  One builds the frame, the other
builds the door.  Neither one is on-site, and neither has met the other.
They are both working from the "spec", or the blueprint.  How likely
do you think it is that the door fits in the frame, that the latch lands
squarely in the hole in the door frame, and that the hinges are set
properly?  I wouldn't give it 1 chance in 100,000, even with experienced
carpenters.

Most of us have been forced to work from the "spec", whether it be the
red book, the structuring conventions, or whatever.  It's actually
surprising to me that so much of it *does* work.

That does not, of couse, permit us to rest or to ignore the problems.
It does, to me, at least, suggest that a massive testing paradigm is
the only thing that can save us.  Imagine if Adobe set up a lab with
every known PostScript interpreter, and a program for running your
code through the mill to test it against all printers, other peoples'
software, include it in TeX output, etc.  Even if they charged a lot
of money for the service, it would have an enormous benefit for the
finished products and the way they all dovetailed together, and
would only serve to cement PostScript's position in multi-platform
computing.

(Glenn) cvn

--
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		NeXT/PostScript developers
 ..{adobe,next}!heaven!glenn		415-326-2974 (NeXTfax 326-2977)