4.0198 Interfaces; Programming the Mac (2/82)
Elaine Brennan & Allen Renear (EDITORS@BROWNVM.BITNET)
Mon, 18 Jun 90 18:03:50 EDT
Humanist Discussion Group, Vol. 4, No. 0198. Monday, 18 Jun 1990.
(1) Date: 18 Jun 90 14:21:00 bst (45 lines)
From: J.Wexler@edinburgh.ac.uk
Subject: Re: 4.0157 Interfaces (4/108)
(2) Date: Mon, 18 Jun 90 9:26 GMT (37 lines)
From: PETERR@vax.oxford.ac.uk
Subject: RE: 4.0190 Interfaces (3/46)
(1) --------------------------------------------------------------------
Date: 18 Jun 90 14:21:00 bst
From: J.Wexler@edinburgh.ac.uk
Subject: Re: 4.0157 Interfaces (4/108)
May I butt in, as a non-subscriber to HUMANIST who just happens to have
seen some of the discussion on graphics-vs-text interfaces? Unless
somebody has disposed of it in earlier correspondence which I haven't
seen, an important point is being missed: text interfaces are (or should
be) good for batch work and complicated "programmed" jobs, with
conditional flow of control and elaborate parameterisation of commands.
It shouldn't surprise or offend anyone if a majority of users prefer
graphics interfaces; that is what suits their style of working. Anybody
who has heavy repetitive work to do, though, will not want to spend
his/her days directing a computer through the tasks with a mouse and
windows, and will be glad to be able to write his/her own programmed,
parameterisable commands and/or batch jobs. The facility to do this
inevitably affects the design of a command language in ways which make
it less attractive for interactive use. In fact, the better the
interface is for "batch" or "pre-programmed" working, the further it is
likely to be from an ideal interactive interface.
Batch mode users often expect the operating system also to do elaborate
scheduling to optimise throughput, meet deadlines, avoid deadly embrace
in resource allocation, and achieve some kind of "fairness" between
multiple users. That means that it should be possible to look at a job
in advance and to know quite a lot about it - whose it is, what
resources it will use, how urgent it is, and so on. This imposes
another set of complications and constraints on the command interface.
User interfaces which allow for all of this are hardly likely to be
intuitive. It is possible to provide a much simpler and more natural
interface for straightforward interactive use. However, there's not
much point in implementing "simple use" as a text interface; people
don't want to have two different command languages (one simple and one
powerful) for a single system. In any case, a graphical interface can
do the job much better for simple easy intuitive interactive use.
Anyway, why worry about it? Both interfaces can co-exist on a single
system, and can usefully interact: for a couple of simple examples, you
can call up a shell command from an icon, or control windows from shell
commands.
John Wexler
Edinburgh Parallel Computing Centre
(2) --------------------------------------------------------------41----
Date: Mon, 18 Jun 90 9:26 GMT
From: PETERR@vax.oxford.ac.uk
Subject: RE: 4.0190 Interfaces (3/46)
Further to Goerwitz's remarks concerning the relative difficulty of
programming a Mac compared to a PC. It is facile and misleading to say
that it is easier to write programs for the PC than for the Mac. What
sort of programs?
Sure, if you want ot write a simple one-off utility for your own use this
is probably correct - though there are lots of programs around for the
Mac (eg Microsoft Basic, Turbo Pascal or Catspaw's excellent Mac
Spitbol) which allow you to implement such a program on the mac very
easily. You can even use the "console" environment in Think C to write
vanilla C programs that use command lines and write printf to the screen
just as they would on any Dossbox. But if you want to write a "GUI"
program with multiple windows etc, all those menus, dialogue boxes,
unlimited fancy fonts - there just ain't any contest. As Morgan's reply
suggests, the Mac is far ahead. This is where six years lead with WIMPS
shows right out. There are shelves full of literature - starting with
the superb Inside Macintosh series, for my money the real reason for the
Mac's success, and extending to Howto guides of every sort - and masses
of fancy third party programming environments that will give you a flying
start in the prickly business of programming for a GUI.
The real point here is that programming for *any* GUI is several orders
of magnitude more difficult than programming for a command line (and
also, I think, several more orders worth-while, which is why some of us
do it). You need the best possible tools, and lots of them, to help you
on the way. Such tools exist for the Mac - I don't see them for the PC.
If you want to compare like with like compare (as Morgan does)
programming the Mac with programming for Windows.Then come back and have
your say.
Peter Robinson
Computers and Manuscripts Project, Oxford University Computing Service.