Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!news.funet.fi!hydra!cc.helsinki.fi!jalkio
From: jalkio@cc.helsinki.fi
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: NeXT Press Release
Message-ID: <1991Apr14.024335.5982@cc.helsinki.fi>
Date: 14 Apr 91 02:43:35 GMT
References: <2323@pdxgate.UUCP> <11007@uwm.edu>
Distribution: comp
Organization: University of Helsinki
Lines: 30

In article <11007@uwm.edu>, gblock@csd4.csd.uwm.edu (Gregory R Block) writes:
> From article <2323@pdxgate.UUCP>, by hal@eecs.cs.pdx.edu (Aaron Harsh):
> 
>>   What do you think it is about DPS that slows things down? You can't draw as
>> many polygons/minute as you could on an Amiga (unless you've got a
>> NeXTDimension), but it doesn't bring every application you try to run to a
>> crawl.
> 
> Interpreted language slows it down.  Period.  No, you can't draw as
> many polygons per minute, and I doubt it will, unless you're running a
> 68090 over a stock 68000.  And whether or not it brings it to a crawl
> doesn't mean it doesn't help to degrade the performance of an
> otherwise lightningly-wicked computer.

Well, actually Display Postscript is an _encoded_ interpreted language.
And when you program, you usually make PostScriptWraps, which are
compiled to binary routines. Display Postscript isn't just "postscript
on the screen", it's more efficient than plain old printer postscript. 

And who cares if the Display Postscript is a bit slower than some else
graphic output system. The key word here is _functionality_. I think
Display Postscript is one of the NeXT's _strong_ points, not a weakness.

By the way, the same philosophy lies behind the choice of the "system
programming language". Objective C sure is a bit slower than plain C,
but which one would you rather program with?

The 68040 has enough power to give for these features and much more.
 
				Jouni Alkio, Helsinki, Finland