Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!accuvax.nwu.edu!acns.nwu.edu!jln
From: jln@acns.nwu.edu (John Norstad)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think against MPW interface war (was Re: MPW wish list)
Message-ID: <3689@accuvax.nwu.edu>
Date: 9 Feb 90 20:17:23 GMT
Sender: news@accuvax.nwu.edu
Organization: Northwestern University
Lines: 76
References:<71.25cdb0c2@waikato.ac.nz> <1990Jan23.065751.29303@peace.waikato.ac.nz> <1990Jan25.003918.2359@cs.UAlberta.CA> <1990Feb6.065019.22828@Neon.Stanford.EDU> <1496@smurf.ira.uka.de>

It is not just esthetics or a matter of taste.  It is possible to argue 
rationally about the merits of a traditional Unix-inspired approach as in 
MPW versus a more Macish direct manipulation approach as in Think C.  
There are also larger related and very important issues which need to be 
discussed. These larger issues are in fact central to the notion of how we 
do computing today and in the future.

I use MPW for one reason - I need the power.  For example (just one, I 
promise - there are many, many others), I write MPW tools to build 
complicated custom resources that are part of Disinfectant.  These tools 
are called by my makefile.  I can't do this in Think C.  

This isn't a matter of taste, it's a matter of fact.  I could not have 
written Disinfectant in Think C (well, I could have, but it would have 
been much, much harder).  Think C is very nice, and MPW could steal lots 
of ideas from it (especially the debugger), and Think C is just fine for 
beginners, and like everybody else I wish that MPW were half as fast as 
Think C, but real programmers use MPW.

I think that more research needs to be done into how far one can go with 
direct manipulation progamming environments and command languages.  MPW 
could certainly use more of this in many areas, and SADE desperately needs 
it (I find SADE so cumbersome that I still do most of my debugging with 
MacsBug).  But I also think that it's incorrect to claim that graphical 
direct manipulation approaches will ever be able to completely replace the 
traditional command language approach.

I have some experience with this sort of thing.  I wrote the original tile 
editor in Odesta Helix.  That was an attempt to implement a graphical 
point-and-click direct manipulation interface for building complicated 
expressions and search criteria in a commercial database program.   The 
basic idea was to let the user use graphical tools to build the parse 
trees for the expressions.

The Helix tile editor is popular in some ignorant quarters, but I think it 
was a failure, and it's the primary reason I no longer work at Odesta. If 
I want to add x and y, I much prefer simply typing "x+y".  Please don't 
make me spend several minutes dragging tiles around, dropping icons into 
them, connecting them together, etc.  I have an absurd example I like to 
show Helix fans - try getting Helix to add 1+1 and display the answer 2 
(starting with an empty relation).  The amount of window opening and 
closing and clicking and dragging you have to go through is absolutely 
ridiculous.  This example is a bit unfair to Helix, since the program was 
not designed to be a calculator, but it does get the point across. Also, 
although I don't follow the new Helix versions closely, I believe that my 
friends at Odesta have improved this situation in recent releases.

Direct manipulation graphical interfaces are indeed a tremendous advance, 
and it's what makes the Mac a Mac.   The Finder is an almost perfect 
example of how truly wonderful this can be.  But there still some areas 
(programming languages and environments, operating system command 
languages, database languages, etc.) where traditional linear languages 
with their complicated syntaxes and ugly warts are still in many cases the 
best way to do things.  If icons are really so much better than 
traditional languages in all contexts, why aren't we still using 
hieroglyhics to communicate?  As a former student of mathematical logic, I 
must in fact insist that formal languages are one of the crowning 
achievements of our civilization, and they will never be totally replaced 
by any sort of graphical language.  This seems completely obvious to me, 
and Mac fanatics who automatically attack any and all traditional 
approches to language issues simply haven't thought the problem through.

One of the most important areas of current research in computer science is 
how one can best integrate these two kinds of languages to get the best of 
both worlds.  Although MPW doesn't yet make enough use of direct 
manipulation, it is one of the best commercial examples to date of such a 
successful marriage.

This has gone beyond the original MPW vs. Think C discussion.  Sorry.  I 
got tired of hacking out C code today, and decided to pontificate about 
one of my pet peeves.  I hope you found it irritating (it was intended to 
be).  Think C and Helix fans should direct their flames to /dev/null.

John Norstad
Northwestern University
jln@acns.nwu.edu