From: byer@adobe.com (Scott Byer)
Subject: Re: OO and PS
Reply-To: byer@adobe.com (Scott Byer)
Organization: Adobe Systems Incorporated
Distribution: usa
Date: Tue, 21 Jul 1992 17:02:16 GMT

Jon Rosen writes

>> [About using PostScript for oo programming].

> Aw, c'mon, this is like saying you can do
> object-oriented programming in FORTRAN.  Sure you can
> if you work hard enough at it.  But why should you have
> to work hard?  Computers are supposed to make things
> easy.  Computer languages are supposed to help.

Remember, OO is a tequnique, not a language specification.
Separating languages into 'OO' and 'non-OO' is perhaps
a little simplistic.  Different languages help with OO
programming techniques to varying degrees.  But you can
do OO in assembly.  Fortran and C are right down there
at the bottom.  C++ and Objective C are closer to the
top.  There are languages that are even better, many that
are worse.

> PostScript, IMHO, most closely resembles FORTH.  Both
> are stack-based Reverse-Polish languages (and I love
> them both dearly :-)  And you could do OO in FORTH too.
> But NEON is a truly object-extended threaded
> interpretive language based on FORTH which makes OO
> programming in a FORTH-like setting a snap.  Why was
> NEON invented?  Because FORTH was simply not up to
> providing all of the ease of use of a good well-designed
> OO language.  The same thing for PostScript, IMHO.

While PostScript resembles FORTH, acting like FORTH wasn't
it's design intent.  And PostScript has a few features
that make it much more amenable to OO programming that
naked FORTH.  Dictionaries (with *arbitrary* keys), type
blindness, and shared VM to start with.  While these
don't make it as friendly to OO as Objective C, they
provide a good base.  A set of procedures and a
communications protocol specification would complete the
picture.

I would like to see PostScript as a language evolve into
something totally OO.  Could you imagine a word-processor
where most of the functionality is because the PostScript
objects react to each other?  Or a PostScript based
user-interface that uses OO to provide constraints and
event handling functionality?

But without some concrete examples of doing OO in
PostScript, it would be difficult to add the things to
the language that would make it fully OO.  PostScript
was evolved - not created out of the blue - and it was
only when a language was created that handled the concrete
examples of what people wanted to put on a page that it
became successful.  I would argue that a similar technique
should be applied to adding OO parts to the language.
Use the language itself as it stands to create several
different versions of the framework for OO programming,
and see what works.

> But history has proven in this industry that if you
> stick your head in the sand and spend time arguing why
> users DON'T need what it is obvious they do (or will)
> need, the industry and success will pass you by.

I'm not going to argue any such thing :-).  Language
features to more easily allow the use of OO techniques
are just one of many things that I think that the language
needs.  Which of those many things is of the highest
priority?

Scott Byer                                   NeXTMail: byer@adobe.com
Adobe Systems Incorporated               These are *my* opinions, and  
1585 Charleston Road, P.O. Box 7900        do not necessarily reflect
Mountain View, CA 94039-7900             the opinions of my employer.
---------------------------------------------------------------------