Aucbvax.5811
fa.info-vax
utcsrgv!utzoo!decvax!ucbvax!info-vax
Sat Jan 16 13:43:23 1982
Re: pandora's box
>From Lars.Ericson@CMU-10A Sat Jan 16 12:36:45 1982
UM, (gulp), UNIX, of course. UNIX currently has a well-supported and
workable LISP (Franz LISP), in which several very large projects (McDermott's
R1 rule-based system, Fox's SRL and IISL knowledge-based systems project)
have been implemented. Purists dislike it, but purists can go to hell,
because they have been failing for years to put up a "respectable" lisp
on the VAX. The NIL project is effectively a failure: first because they
selected VMS, an obviously unworkable machine for on-line, programmer-
oriented interaction, and second because they fell prey to personality
squabbles (I hear) in which one purist kept re-implementing the code
incompatibly with another purist, and little purity wars developed. Now
it would appear that the work on NIL will be subsumed under the "common
LISP" effort at CMU and elsewhere, which I assume will produce a perfect
LISP after a delay of at least one and perhaps two years. Of course,
there is ISI (?)'s VAX INTERLISP project, but I presume Mark Miller wants
MACLISP, and besides, that appears to be a year away also.
As for EMACS -- well, the only decent EMACS-like editor is Gosling
EMACS on UNIX. It is true that this has been transported to Eunice, but
several highly important features are missing. The most important is
the ability to split the screen into two windows, and type commands
directly to a OS command language interpreter (i.e., SHELL) and have
them executed. This includes the ability to lift input and output out
of the "shell window" and stick it into some other editing buffer, and
vice versa. This also means that you can start a LISP in the Shell
window, and talk to it while concurrently editing functions in another
window. The second important thing is the minor annoyance of tens of
missing user packages. For example, when I go to invoke the paragraph
justifier in text mode -- or even if I attempt to go into text mode
from "normal" mode in VMS Emacs, the package isn't there. I assume this
is commonly the case.
Why can't Shell windows be implemented? Eunice doesn't do "mpxio" right,
a terminal I/O package put out with the Berkeley distribution. This is
to be expected, of course -- the hardest part of any emulation is the
I/O structure -- but it is certainly not abetted in any way by the intricate
unusable and incomprehensible facilities of VMS I/O, which are designed
for the Fortran and Cobol accounts-receivable-package writers of the
world. Of course, these people are used to being degraded and spat upon
with Thalidomide-victimized manufacturer's software, but I don't think
anybody in the computer science community should really be forced to
put up with it. The favorite reasons (generally) *administrators* (a
dirty word) use for selecting VMS is "maintainability". Our Psychology
department selected VMS for this reason, against the loud protests of
all who actually had to use the machine. One CMU CSD project, R1, uses
VMS, but that is because it is writing company software -- a VAX
configuration program for DEC.
If Texas Instruments decides to go with VMS, that is their loss -- why
not buy an IBM or CDC machine instead? You'll get more cycles. As for
me, I am reminded of heaven every time I log into a UNIX machine, and
I hope I never have to touch a VMS machine, except when converting some
program foolishly (or inadvertently -- when force to by an errant
*adminstrator*) written on a VMS machine over to a UNIX system.
-- Larswe
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
