"Lex Spoon" <lex at cc.gatech.edu> wrote:

> Martin Wirblat <sql.mawi at t-link.de> wrote:
> > Here are Squeak's current problems ordered by importance:
> > 
> > 1) library
> > 2) speed

> 
> I don't see speed as an issue for us.  Why do you put it at the #2 slot?
>  We aren't going to win over users who need a *really* fast
> program-execution system.  On the other hand, I worry that if we think
> about speed too much, we might mess up some of the things that are
> great.
Well, I see speed as an issue because on a regular seeming basis
somebody or other manages to put something in the image that cripples
interactive performance. Basic compute speed is really pretty
impressive - even on a very slow machine like my 600MHz ARM box - but
the UI varies from ok to unusable depending on update level.

OK, so I can hear people telling me to get a real machine (I actually
have several, including a dual cpu 1GHz pMac and a 1.5GHz pBook) but
honestly, a machine that can hit 29 Dorado on the GreenBook benchmarks
really shouldn't have problems making a menu select at decent speed nor
a text view type as fast as my ancient arthritic fingers can hit keys.
The venerable ActiveBook managed all of 27% Dorado and could do better.
Yes, monochrome and yes, no window system to get in the way, but still.

Besides, there are lots of potential Squeak machines with the same cpu
and memory system that I have, plus the burden of winCE; think of all
those 2/4/600 MHz PDAs out there, yearning for decent software. And
don't forget the LinkSys/ASUS NAS boxlets in need of software. We can
do better.

And besides (again) with graphics/UI performance improved sensibly we
could write Doom in Squeak.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Computers talk to each other worse than their designers do.