🚀 go-pugleaf

Ed Nather, on wysiwyg, particularly relating to the computation required:
> I think this may be the crux of the disagreement -- if there is one.  There
> is a real difference in trying to get something to work on existing computers
> and deciding on the preferred method in the abstract.  As an example, assume
> you have available a Cray-class computer that is cheap ($499.95), and enough
> backing ("I need a *big* tax write-off this year ...") to build your "dream
> formatter."  Do you build a "dot-command" formatter or WYSIWYG?

Beyond the computational ability, you have to consider what it costs to
write the software.  A WYSIWYG system is going to have to do everything a
"dot command" system does, but it also has to handle a lot of presentation
issues that never arise in the dot command system (even when the dot
command system is preparing its output).  In a sense, a wysiwyg system must
behave in an "atemporal" fashion--it can't be written in a way that assumes
making "passes" over the data.  (This is bordering on the philosophical,
but it's near the heart of some implementation issues.)

> Try to guess what computing power you'll have on your desk in 10 year's time.
> (I've just been looking at a plug-in board that turns an IBM/PC into a
> Vax 11/750 equivalent ...) THEN decide what kind of text manipulator you
> would *really* like to be using right now ...

But try to guess what sort of computing power it will take to do full
wysiwyg with all of the capabilities people will need/want.  Right now,
embedded-command systems are leading the way into the higher end of
computer based document preparation.  Wysiwyg systems are trying to keep
up.  The sort of power we can put on a desktop right now is barely enough
for doing what we need, as long as documents don't get TOO big and the
features don't get TOO fancy.  We need a BIG increment of computing speed
to give wysiwyg a comfortable place to work.  I would think that maybe 2-3x
a 16MHz 68020 would put us in a comfortable place for the CPU

BUT the disk speed is another problem, perhaps the major one.  Disks are
getting cheaper but they aren't getting that much faster (in seek time in
particular).  Yes, I know that all you have to do is move the file into
memory, and memory is rapidly getting cheaper.  That doesn't help enough,
for two reasons:  (1) You still have to get the file in and out of memory,
and that involves either a looong startup time or some messy approach of
bringing it in piecemeal while you try to interact with the user.  (2) You
MUST keep moving changes out to the disk as they happen, against the
possibility of machine failure.  Remember that this animal is sitting on a
desktop; it's not running on conditioned power nor is there likely to be an
UPS, and people are prone to turning it off without thinking first or to
kicking the plug out of the wall!  (Actually I see disk drives as a major
impediment to speeding up a lot of systems.)  We need some sort of break-
through in cheap, nonvolatile, read/write storage--mainly, FAST access
times.  I'm thinking in terms of millisecond or less latency, and I don't
see how any sort of conventional disk is going to get there.
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Reality?  Gad, that's worse than puberty!