> Subject: a minimal interface
...
> End-user functionality has improved drastically, certainly, but the users are
> still encumbered with a bewildering array of interfaces, options, and
> conventions. And programmers are forced to learn myriad details to package
> useful algorithms in a friendly fashion.
>
> So, a suggestion: in any plan for a next generation astronomical package
> consider using only a very thin veneer, if any at all, between it and an
> underlying operating environment. In particular, go ahead and use UNIX, CDE (X
> Windows and Motif), POSIX threads, RPC and sockets APIs directly and existing
> scripting languages such as perl.
...
> My experience has shown me that the "thin or no veneer" approach has direct
> advantages of simplicity and performance. It also takes maximum advantage of
> existing knowledge, both for programmers and the users, ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I do not think that getting cozy with the operating system will be a
convenience for users. Quite the contrary, as is illustrated by a
couple of examples. Consider the recent history when the big switch
from VMS to UNIX occurred in astronomy departments: we all know people
who had decided that they ought to switch OS's to take advantage of
some new capabilities (or prices, or whatever) but "couldn't" because
they (or their software) were wedded to some VMS features. Similarly,
users of some package XXX won't switch to New&Improved package YYY
because they don't want to learn a new user interface -- a "thin or
no veneer" is only attractive if you like what lies underneath.
Astronomers who enjoy programming per se probably like programming
under UNIX (at least they probably like it more than the main
alternative OS's), and they may have a great time writing elaborate
Perl scripts, but these users form a minority. In my experience, most
astronomers find UNIX a real irritation ("why is it 'ls' instead of
something sensible like 'dir'?"), and are glad that they don't every
have to deal with UNIX at a low level. They certainly don't do Perl
programming; they can't write a Bourne-shell script; etc.
> In summary, I am suggesting a minimalistic approach to any new designs...
> ...What I am emphasizing is that any new design process include
> careful attention to keeping the foundation and basic infrastructure as small
> as possible, and a big step in doing so is reducing the need for an artificial
> portability layer.
Certainly it is always desirable to keep infrastructure as small as
possible, but the existing standards (RPC, POSIX threads, ...) are
low-level programming standards, far below the level at which an
applications programmer should have to work. However, the value of
these standards encourages one to think about the value of higher-level
standards -- specifically, standards to promote portable tasks.
Standards that promote portable tasks are precisely what will allow
users to take advantage of their existing knowledge, since they can
continue to work in their environment of choice, whether it be Perl,
IDL, IRAF, etc.
-Will
William Deich |
NFRA | Internet: will@nfra.nl
Postbus 2 | Phone: (+31) 5219 7244
7990 AA Dwingeloo | Fax: (+31) 5219 7332
The Netherlands |