Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!eecae!netnews.upenn.edu!rutgers!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: Human vs. machine input (was: Re: Behaviour of setjmp/longjmp ...)
Message-ID: <7748@chinet.chi.il.us>
Date: 17 Feb 89 20:22:02 GMT
References: <25@torsqnt.UUCP> <225800127@uxe.cso.uiuc.edu> <7697@chinet.chi.il.us> <1016@auspex.UUCP> <7709@chinet.chi.il.us> <1023@auspex.UUCP>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 42

In article <1023@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
[RE: human input vs. programmed]
>What is a "monolithic application"? "vi", "emacs", or any one of N
>screen editors? UNIX not only *can* do that, but *does* do it, quite
>often; if it *couldn't* run such an editor, I'd be pretty ticked off. 

A monolithic application is one where the user must interact directly
with the program, and outputs go to specific devices known by the
program.  Seems like a nice concept, since everything can be optimized.
However in many situations, the user wants to do nearly repetitive
operations but there is no way to supply programmed input.  For example
we have a map-drawing program with a handy-dandy point-and-select
interface.  The user had prepared maps of each state with data by
counties (fortunately the data could be imported).  The *only* way to
select a map to print is to highlight it's name in a displayed list
and select it, and a high-res printout takes about 15 or 20 minutes.
So, instead of being able to prepare a list of commands to be issued
automatically one after another and going home he has to wait around
and use the (easier?) method of visual selection.
I could give several other real-world examples, but the principle here
is plain.  Much work only involves a small variation from the last
time a program was run and an extremely easy way to avoid work is to
gather up the variable parts first with a separate program that prompts
or does a table lookup, merge it with the standard inputs and feed it
to the main program without user intervention.  With standard unix-type
utilities this is generally no problem, and it can easily be allowed
by the program itself by making provisions for reading commands from
and input file *if* all the commands can be represented in the file
data.  That's the real problem with human-engineered input styles - how
do you represent something dynamic that is highlighted on the screen  
in a command file, or even something like a key-up event?

>Yes, it's *nice* to be able to glue programs together.  The existence of
>many operating systems that, unfortunately, don't let you do that as
>conveniently as UNIX, but that people can still use, however
>inconveniently, to get their job done proves that such OSes are not
>"fairly useless", however.

I'll admit that I should have posed the question above instead of
reacting with a flame.

Les Mikesell