steve@siemens.UUCP (Steve Clark) (12/09/87)
This article should stir up a little controversy, I hope. Unix is the Fortran of operating systems. ---------------------------------------- Somebody once gave a talk with this title, about 7 years ago, at Carnegie- Mellon U. It turns out he is fairly correct, but not as correct as he thought. By being such a pervasive standard, Fortran held back the practice of Computer Science for many years after the state of the art had advanced beyond it. Unix is doing the same thing in the realm of operating systems, although to a lesser degree. Somehow Unix is more flexible and adaptable than Fortran, even though it is just about as widespread and just about as standardized. I have two new points to make today: 1) Why isn't Lisp a Fortran? Will Common Lisp be the Fortran of Lisp? (Answer left as an exercise to reader. Scheme fans will no doubt have different answers than most of the rest of us.) 2) I assert that Emacs is the Fortran of editors. Once you learn Emacs well (I mean really well, like just about everyone reading this list), it is hard to find an editor worth the trouble of learning, isn't it? Even if the editor has theoretically superior features, you'd rather stick with trusty old Emacs. Besides, the new editor doesn't even have EQUIVALENCE - oops, I mean paren-balancing. Its proponents say you don't need paren-balancing, it has a different way of achieving the same effect. Well, if it's doing the same thing, then what's so great about it? Besides, I would have to throw away my personal bag of tricks I've developed to get around all the deficiencies of Emacs. In conclusion, I assert (admittedly without much argument) that Emacs and CL are, at least with respect to files and editing, Fortrans. The "new" ways (which aren't that new) are database-type files and structure editing.
pds@quintus.UUCP (Peter Schachte) (12/10/87)
In article <332@siemens.UUCP>, steve@siemens.UUCP (Steve Clark) writes: > ... Will Common Lisp be the Fortran of Lisp? No, CommonLisp is more like the Ada of Lisps. A standardized committee effort, designed to include everything including the kitchen sink. Why didn't CommonLisp take the more modern approach of having most of the goodies out in libraries (Modules to CommonLispers)? > 2) I assert that Emacs is the Fortran of editors. The really sad thing about emacs is that it doesn't have a way to highlight selected regions of a buffer. This renders a mouse pretty much useless except for positioning. If emacs could hightlight regions, one could select words, sentences, and paragraphs with a mouse and then delete them or copy them with a single keystroke. I've used a version of emacs that uses a mouse to do these sorts of things WITHOUT highlighting them first, and this is worse than nothing. You just don't know what you're doing until it's done. Sure, you can get it back if you deleted something you wanted, but first you have to figure out what happened. The visual feedback BEFORE the operation is committed to is important. All of you hardcore emacsers are screeching at the thought of handling a rodent for editing, I know. But for manipulating chunks of text (or structure), a mouse is the ideal tool. And the real idea is to use one hand to move and click the mouse, and the other chording keys on the keyboard to indicate WHAT to do with the chunk you are selecting with the mouse. Interlisp-D uses the scheme that SHIFT means to copy what you have selected to wherever your typein would go, and CONTROL means to delete it. Of course, both means to move it. (Note that what you select is not constrained to have your typein point at one end of it, as does emacs.) I might even LIKE emacs if it could let me do that. Except that in LISP mode, I'd want do be selecting S-expressions, and in text mode, words and sentences. And I'd want emacs to do my formatting for me completely automatically. Just like it can fill paragraphs as I type. Given emacs as it is now, thought, I'd say emacs is worse than a FORTRAN. At least FORTRAN could handle new technology (terminals with variable-length lines) when it came along. Emacs will need some work. Or is there a hacked-up emacs that will do that now? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
barmar@think.COM (Barry Margolin) (12/11/87)
In article <453@cresswell.quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >The really sad thing about emacs is that it doesn't have a way to >highlight selected regions of a buffer. This renders a mouse pretty >much useless except for positioning. If emacs could hightlight >regions, one could select words, sentences, and paragraphs with a mouse >and then delete them or copy them with a single keystroke. I've used >a version of emacs that uses a mouse to do these sorts of things >WITHOUT highlighting them first, and this is worse than nothing. You >just don't know what you're doing until it's done. Sure, you can get >it back if you deleted something you wanted, but first you have to >figure out what happened. The visual feedback BEFORE the operation is >committed to is important. What universal law says that an Emacs-style editor can't highlight things or use a mouse? Zmacs, the Emacs-style editor on MIT-derived Lisp Machines, does both of these things. When you invoke a command that marks a region, the region is underlined (there is an option to use inverse video instead of underlining). And I have used at least one Unix implementation of Emacs that always shows the character under the mark in inverse video (this can be confusing on a terminal whose cursor is a non-blinking block, since you wouldn't be able to tell point from mark except by typing Control-F and seeing which one moves). As for mouse support, Zmacs allows you to move around the buffer and mark regions using the mouse. This is appropriately context-sensitive, so that in Lisp Mode you can point to a parenthesis and mark the entire S-expression with a mouse click. Symbolics Genera 7.0 and beyond implements much more extensive support; for example, you can point to a line of code and set a breakpoint with the mouse. GNU Emacs also implements mouse support when it is run under the X Window System. If you are going to complain about particular editors, do so. But "EMACS" is generic, and refers to a large class of editors running on a wide variety of computer systems ranging from PC's to mainframes. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
dzzr@beta.UUCP (Douglas J Roberts) (12/12/87)
> > What universal law says that an Emacs-style editor can't highlight > things or use a mouse? Zmacs, the Emacs-style editor on MIT-derived > Lisp Machines, does both of these things. When you invoke a command > that marks a region, the region is underlined (there is an option to > use inverse video instead of underlining). > Gnu EMACS on a Sun also has a mouse interface, but I think the highlighting (there currently is none that I know of) and paren checking could be improved. Zmacs has an execllent paren checker that causes the backward matching paren to blink, showing the matching paren at (just before) the current cursor position. If (when) Gnu is given better paren checking capabilities and mouse-selectable region highlighting I will be quite happy to let my old Symbolics 3600 gather dust in the corner while I use Gnu with KEE and LISP on a Sun. --Doug -- --------------------------------------------------------------- Doug Roberts dzzr@lanl.gov ---------------------------------------------------------------
alex@umbc3.UMD.EDU (Alex S. Crain) (12/12/87)
In article <13276@beta.UUCP> dzzr@beta.UUCP (Douglas J Roberts) writes: >> What universal law says that an Emacs-style editor can't highlight >> things or use a mouse? Has anyone ever tried to implement highlighting in GNU? I would REALLY like to have this but I haven't dug deep enough into the code to see how to do it. If anyone has ever tried, I would appreciatteany leads to a starting point, and or even a description off what I'm going to be looking at if//when I go in myself. ThanX in advance. :alex.
rodney@pawl21.pawl.rpi.edu (Rodney Peck) (12/16/87)
In article <638@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: >In article <13276@beta.UUCP> dzzr@beta.UUCP (Douglas J Roberts) writes: >>> What universal law says that an Emacs-style editor can't highlight >>> things or use a mouse? > >Has anyone ever tried to implement highlighting in GNU? I would REALLY like >If anyone has ever tried, I would appreciatteany leads to a starting point, The Symbolics Lisp machines have an editor called Zmacs which supports highlighting and mouse control. Perhaps you should find a Symbolics machine and mimic it. I think that mousing and highlighting would be great. I'm using a sun 3/50 right now. Rodney
shebs@utah-orion.UUCP (Stanley T. Shebs) (01/21/88)
In article <332@siemens.UUCP> steve@siemens.UUCP (Steve Clark) writes: >By being such a pervasive standard, Fortran held back the practice of Computer >Science for many years after the state of the art had advanced beyond it. This is an old chestnut, at least to CS types. David Gries (or Kenneth Wilson?) wrote something a couple years ago, to the effect that scientific programmers kept using Fortran because all the new languages offered few or no advantages. For one thing, most of the languages are procedural, so the process of converting specification ("use an adaptive grid method") to code ("do i = 1, 50") remains basically the same. We in CS make a big fuss over recursion, data structures, etc, but users of languages have more important concern. Claims that "language X has held back the practice of Y" are pretty suspect - I find the hard parts of CS to be things like logics, algorithms, and representations, which have relatively little to do with programming languages. >Unix is doing the same thing in the realm of operating systems, although >to a lesser degree. Somehow Unix is more flexible and adaptable than Fortran, >even though it is just about as widespread and just about as standardized. I don't see Unix holding anything back either. What I see is that the term "Unix" is being applied to almost any operating system with the capability for forked processes in separate address spaces. 1/2 :-) >2) I assert that Emacs is the Fortran of editors. Fine by me. As a user of editors, I'm more interested in mundane issues like how many machines it's on and how reliable it is. I agree that Emacs has numerous deficiencies - I've blown away whole buffers with ^W, have never been comfortable with the idea of deleting things to make copies of them, and hate to use the control key. But what I hate even more is editors that only work on one kind of terminal, and using seven different editors. >In conclusion, I assert (admittedly without much argument) that Emacs and >CL are, at least with respect to files and editing, Fortrans. The "new" >ways (which aren't that new) are database-type files and structure editing. I also agree that these are new ways. What I *don't* agree with here is the unstated assumption that "old" ways should be abandoned the moment "new" ways come along. There have been too many times I've watched people screwing around with something new and fancy - and inefficient and unreliable and nonportable. I really hate having my productivity cut into by some half-thought-out and half-implemented system! In the case of database files and structure editing, no one has yet come up with something that offers clear and immediate benefits without a host of caveats and drawbacks. Interlisp could have been the standard Lisp of the 80s if people had put as much thought and effort into its design and implementation as have gone into Emacs and Unix and Common Lisp, instead of patching kludges with worse kludges. The success of a software idea depends as much on the quality and availability of an implementation, as on the worth of the idea itself. The history of CS is full of examples of this, but of course those who are ignorant of history *inevitably* repeat it... stan shebs shebs@cs.utah.edu