Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!conrad
From: conrad@cgl.ucsf.edu (Conrad Huang)
Newsgroups: comp.sys.next
Subject: Re: NextStep and NeWS...
Keywords: NextStep,NeWS,Postscript
Message-ID: <11532@cgl.ucsf.EDU>
Date: 20 Apr 89 21:50:59 GMT
References: <1041@nixctc.DE> <8530@polya.Stanford.EDU> <3901@ficc.uu.net> <4759@pt.cs.cmu.edu> <3918@ficc.uu.net> <4779@pt.cs.cmu.edu>
Sender: daemon@cgl.ucsf.edu
Reply-To: conrad@zeno.mmwb.ucsf.edu.UUCP (Conrad Huang)
Organization: Computer Graphics Lab, UCSF
Lines: 91

In article <4779@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes:
>Well, I think the confusion here is perhaps that making NextStep/NeWS
>comparisons is the wrong comparison.  It would be more appropriate to
>compare NextStep with the Mac user-interface or Open Look...  It would
>also be more appropriate to compare DPS with NeWS.

Perhaps comparing user interface specifications is appropriate, but comparing
DPS with NeWS definitely is not.  DPS provides output capabilities only, while
NeWS is a complete window environment *including input management*.  It is
possible to write a program for NeWS and be guaranteed that it will work on
most NeWS systems (modulo bugs) but there is *absolutely no way* to write a
portable DPS program.

>NextStep defines a user-interface, DPS/Objective-C/C provide a base
>for an implementation of it.  If you want to write your own user-interface,
>then you can program it in DPS if you wish.  We are just saying that
>programming in DPS (or NeWS) is, in general, a pain.

The problem with trying to program in DPS is that there is no way to
communicate with the window server other than through the AppKit.  (I
have read parts of the manual but by no means all, so correct me if I'm
wrong.)  This means you must at least use Objective C to create an
Application class object.

>Let's also not forget that an important part of NextStep is InterfaceBuilder,
>which let's one build NextStep user-interfaces for applications with
>very little to no programming (other than the guts of your application).

If InterfaceBuilder is an integral part of NextStep, I am certainly glad
that "Interface Builder is greatly changed in its appearance" (from the
"0.9/1.0 Release Description").  The version on Release 0.8 is at best a
toy.  Better data flow style editors have been built, even for the Evans
& Sutherland PS300 function networks (my one gratuitous insult in this
posting :-).  [Even further off the subject, the PS300 function networks
are hell, regardless of what they say in comp.graphics.]

>>The second advantage to this is that more of the processing of the user-
>>interface can go on in the display server, freeing the host and communication
>>channel of the burden. [ division of labor ]
>
>The importance of this is somewhat questionable (I think).  The fact that
>people even think about this these days is because the environment they
>are used to (e.g., UNIX with sockets) just doesn't do message passing
>fast enough.  When you are doing animations (for example), do you really
>want to write your animation in Postscript, of course not, and we don't.
>What if your animation needs to be synchronized with sound effects?  Do
>you write that all in Postscript also?  No, of course not.  The basic problem
>with X/NeWS/... environments is that the generally run on top of UNIX, and
>UNIX just doesn't have the right primitives to support them (in terms of
>high speed message passing).  We have overcome this problem by using Mach
>primitives which allow us to synchronize with the window server about 10
>times faster than with traditional UNIX facilities.

Unfortunately, those of us on the same network but not running Mach cannot
"synchronize with the window server" at all.  The advantage of NeWS is that
I can run my application on our Vax and have the graphics appear on our Sun
*using only standard network software*.  With some of the computation that
we would like to do, animating the results requires a supercomputer class
CPU.  Unfortunately, I don't know of many such systems that run Mach or
speak with NeXT window systems.  I certainly agree that the greater
the bandwidth between the application and the window server, the greater the
programming flexibility.  But connectivity should count for something as well.

>>Personally, I think a lisp-like language would be better than postscript, but
>>there is a certain historical advantage to sticking with PS.
>
>Then you'll be happy to use Common Lisp with support for NextStep in our 1.0
>release.

The main gripe I have with NextStep currently is that there is no *simple*
graphics access.  If I am working on an application that will have a user
interface, then NextStep may be helpful.  But I can't simply use the graphics
to help debug a program.  When my translator/compiler runs, I'd like to
show my DAG and make sure it is right.  I'd also like to highlight nodes when
I generate code for them.  To do this, I must create a whole lot of code that
will eventually be discarded (or at least archived) once my program works
properly.  The time investment for this debugging code is greater than I am
willing to spend and I've resorted to the old classic "print statement" method.
With a nice platform like the NeXT, this is somehow distasteful.

>-- 
>Avadis Tevanian, Jr.    (Avie)
>Chief Operating System Scientist
>NeXT, Inc.
>avie@cs.cmu.edu or avie@NeXT.com
>-- 

Eagerly awaiting 0.9,

Conrad Huang
conrad@cgl.ucsf.edu