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 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.