Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-june!uw-entropy!mica!charlie
From: charlie@mica.stat.washington.edu (Charlie Geyer)
Newsgroups: comp.lang.c
Subject: Re: Iconitis
Message-ID: <1364@uw-entropy.ms.washington.edu>
Date: 7 Apr 89 21:09:47 GMT
References: <1930@dataio.Data-IO.COM> <11555@lanl.gov> <1360@uw-entropy.ms.washington.edu> <38800@think.UUCP>
Sender: news@uw-entropy.ms.washington.edu
Reply-To: charlie@mica.stat.washington.edu (Charlie Geyer)
Organization: UW Statistics, Seattle
Lines: 22
Summary:
Expires:
Sender:
Followup-To:


In article <1360@uw-entropy.ms.washington.edu> I wrote:

    The main defect of any menu-driven application, whether it uses
  mice and icons or not, is that it is not programmable and will do
  nothing not thought of by the original programmer, who probably had
  very little idea what you want done.

In article <38800@think.UUCP> barmar@kulla.think.com.UUCP (Barry
Margolin) replies:

> You are comparing two unrelated qualities here.  There are many
> keyboard-driven applications that are not user-extensible.  And there
> is nothing inherent in menus that prevents user-extensions.

except that not all useful "extensions" can be usefully be done by
adding options to menus.  That's why I said "programmable."

It's a truism that every applications program defines a new
programming language or uses an old one.  Most are incoherent, but they
are languages none the less.  Icons are baby talk.  O. K. for some
purposes, but not for most things.