[6280] in s-news-athena
Ease of use
daemon@ATHENA.MIT.EDU (jmc@research.att.com)
Fri Jan 27 11:10:48 1995
From: jmc@research.att.com
Date: Fri, 27 Jan 95 10:04 EST
Original-From: jmc
To: S-news@utstat.utoronto.ca
The various comments on this topic recently touch on some issues I've
been considering often in my current work, so I hope S-news readers
will excuse a bit of philosophy. (There will be nothing useful in
this message, so those who wish can stop reading now.)
I feel sympathetic, more or less, to all sides of the discussion.
Yes, it's hard to learn a language with so many functions and which
can be used in so many different ways. By the way, it's even harder
to write, say, a book that makes it easier to learn the language.
Non-programming interfaces, like spreadsheets, are great if they touch
close enough on what you want to do. There are two potential
downsides to such interfaces, though. First, they may lead people to
painful contortions in some attempts to "program" with them.
Second, they offer a strong temptation to choose something easy from
the interface, even if you know this is not the appropriate analysis.
My hope for the future is that non-programming interfaces (ok, GUI's)
will proliferate, along with other tools to make life easier for
specialized applications and beginning users.
But -- this is my main point -- these interfaces should themselves be
based on a powerful, general programming language and environment.
Then the user who comes up against the interface's limitations is led,
reasonably painlessly, to devise extensions or to work in the more
general programming environment. The interface itself can have a
window into that environment.
Supporting this kind of relationship is one of the incentives for the
current research on S.
My favorite supporting example is a very different one, but the
parallels are relevant: emacs. I believe emacs is the best general
editing environment in Unix for serious projects. Grant me that for
the moment, then: Why is this true? There are a number of reasons,
but one that strikes me is that it is based on its own version of the
Lisp language. This may not be 100% ideal, but it means that emacs
can be adapted and extended by working in a good programming
environment. That is exactly what has happened, and to me it explains
much of the superiority of emacs.
My upside hope is that future versions of S/S-Plus can do the same
thing (maybe even better) for data-intensive programming.
John Chambers
