Guest User


a guest
Oct 20th, 2014
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 10.94 KB | None | 0 0
  1. I started to reply at length to the many misstatements in your
  2. message. I don't really have a problem with your excitement about
  3. Emacs. I use Emacs a lot. I have for over 20 years. I'm typing to
  4. it now. BUT to the extent that you try to claim it replicates Genera,
  5. you're both kidding yourself (which I don't really care about one way
  6. or another) and engaging in historical revisionism (which does trouble
  7. me and is the reason I'm responding here).
  9. The value in Genera's Dynamic Windows is NOT about "completion" it's
  10. about object-oriented connected-ness of the entire system. You aren't
  11. clicking on the "name" in dynamic windows. You are clicking on the EQ
  12. object. This means you can, for example, mouse an instance of
  13. something and get that instance as an object to inspect and
  14. manipulate. Emacs has NO basis for equivalent stuff. None. If
  15. you've seen Genera only through screen shots, you could never imagine.
  16. It's like trying to explain someone whose only seen streams of text
  17. what an object pointer is.
  19. Last night on my Lisp Machine I was frustrated by the absence of NT
  20. file support. I had no idea how file support was implemented, but I had
  21. a general working understanding of how the Lisp Machine was organized,
  22. and within a small number of hours I had learned about how to extend the
  23. operating system to talk to NT over TCP and implemented a new set of classes
  24. so that I could transparently talk to my NT box over my local ethernet.
  25. A lot of my ability to do this was enabled by the ability to point and click
  26. on objects in order to debug them and inspect them without any fear or
  27. confusion about whether I was using the right sources, the right packages,
  28. etc.
  30. I cannot by any stretch of the imagination sit down at Emacs and do
  31. the equivalent thing. I can't learn about even how to extend Emacs
  32. itself in so short a time, much less use Emacs to help me learn about
  33. Windows NT or Unix or whatever. Sure, Emacs has some
  34. self-documentation. Sure, the sources are there. But for example,
  35. there's no assurance when I read in a source file that it's the same
  36. source file that I loaded. The lisp machine keeps meticulous records
  37. not only of which source files are loaded and from where but which
  38. functions have been patched by which files. That means I can't make a
  39. mistake and use the wrong tags file or the wrong version of files
  40. backing up a tags file. I was confused by the behavior of something
  41. that and I looked at its source, it correctly told me about the patch
  42. file that had redefined the function rather than just leading me to
  43. believe that the system source was correct. There are myriad subtle
  44. ways in which Emacs is only a pale shadow of Zmacs.
  46. Not resources. Objects. All objects. Not just the heavyweight ones.
  47. Lists. Integers. I somehow don't believe you when you say this is the
  48. same as what Genera does.
  50. The usual thing DW enables is the debugging of things that the
  51. person did NOT make part of the standard interface. Pointing to a UI
  52. tool and saying it allows you to plan for structured debugging of
  53. something is missing the point.
  55. Or maybe you're saying that Garnet allows me to cross the boundary into
  56. the internals of systems. Maybe I'm missing out.
  58. When you can make the claim that if you teach me a few paragraphs
  59. worth of stuff, I will have all of the information I need in order to
  60. bootstrap myself into a complete understanding of the entire operating
  61. system and all of its conventions, I'll believe you Garnet and X are
  62. as powerful as Genera and Dynamic Windows. Until then, I'll continue
  63. to believe they are different. Incidentally, I'm dying to know that
  64. there is a tool that will do all that Genera could do only for stock
  65. hardware becuase the stack of books I need to buy in order to be
  66. equivalently competent with other systems is daunting and I could
  67. really do with the savings in time, energy, and money of learning things
  68. about standard systems in the way I've been doing...
  70. I don't even find Emacs itself to be equivalently self-documenting and
  71. easy to get around in, much less the many systems that Emacs touches.
  73. Look, I used to literally sit around in my office at MIT years ago and
  74. fuss at people who said Lisp Machines were everything. (I used and liked
  75. Lisp Machines but I myself didn't think they were what they were because
  76. of the hardware--they were what they were because of the software and
  77. the ideas behind them.) I used to ask people "What's an impossible thing
  78. to do? I'm looking for something to do this afternoon in Teco that people
  79. say can only do on Lisp Machines." People said Zmail. I wrote the
  80. approximate equivalent in Teco--filters, and all that. They wanted a
  81. filter menu. I wrote that in Teco. They wanted mouse handling. (That
  82. was tough because PDP10's didn't have mice, but I used my imagination a
  83. little and arranged a mouse protocol from Lisp Machines so you could telnet
  84. to the teco-based Emacs and click on my filter menus.) They wanted
  85. Zmail init files. I wrote a Lisp compiler in Teco so that I could use
  86. people's Zmail init files unmodified. It was about 20K words of Teco
  87. code, btw. Code was smaller back then... sigh.
  89. Anyway, I *know* what it is to look at functionality and duplicate it
  90. elsewhere. It CAN be done. I am not saying it can't. What I'm
  91. saying is that it has not been done, and it's a crying shame. Few
  92. people even know there ever WAS a lisp machine, and those who do are
  93. mostly not rich enough personally to invest the time to duplicate what
  94. was there. Many people spent a big chunk of their lives investing in this
  95. dream and it didn't pan out quite as we wish. Ok. Sometimes other
  96. events win out--not always even for the right reasons. Or at least for
  97. the reasons you wish. But don't add insult to injury to say that the
  98. losers in battles such as these had nothing to offer.
  100. Common Lisp beat out Interlisp, and maybe for good reasons but it doesn't
  101. mean Interlisp had nothing to offer--some very good ideas got lost in the
  102. shuffle and I don't pretend that Common Lisp just obviously had a better
  103. way. Java is going to beat out Smalltalk perhaps, but that doesn't mean
  104. Java is better than Smalltalk. We owe it to the losers in these little
  105. skirmishes to make sure that, if nothing else, the good ideas are not lost
  106. along with the framework. And we do not accomplish that by defining
  107. that there was nothing lost. That's both callous to those who worked
  108. hard on these other things and short-sighted to the future, which might one
  109. day care about the things that got lost.
  111. There are still Lisp Machines around. If you want to opine on them
  112. with authority, get one and use it. There is no substitute for first-hand
  113. data in situations like this.
  115. Here are a few, not intended to be complete, but to give you a spirit
  116. of the degre of "precision" in Zmacs commands that distinguish them from
  117. Emacs commands:
  119. * Tags Multiple Query Replace From Buffer
  121. This is an extension to Tags Multiple Query Replace (which does a
  122. multiple-strings-at-once Query Replace over a Tags Table; and,
  123. incidentally, the Tags Tables don't have to be files--the Lisp
  124. Machine just makes them up on the fly from spaces of buffers, from
  125. system definitions, etc. on user request). It allows you to put
  126. pairs of elements and their replacements in a buffer and have
  127. all replaced in parallel.
  129. As with all operations of this kind (including Tags operations and
  130. other mapping operations like "Edit Compiler Warnings"), this creates
  131. a "possibilities buffer" which is a physical manifestation of keeping
  132. your finger on where you were in the middle of a complex operation
  133. so that if you see something else you want to do while you are
  134. doing the replacement, you can suspend the operation and resume it
  135. later perhaps after doing other replacements or edits. When editing
  136. the ANSI CL spec, something I refused to do on anything but a Lisp
  137. Machine, I often had dozens of these buffers stacked up in simultaneous
  138. use and was successfully able to resume them to make sure all completed
  139. while allowing the system to accomodate my "focus".
  141. * Source Compare
  143. This command allows you to run a source comparision program (which
  144. itself is just presentationally way better than Unix diff or
  145. emacs compare-windows). There was a public version of a source
  146. comparison program written by someone a while back that is as good
  147. but is in CL and isn't integrated into Emacs. Alas. But in addition
  148. to the presentational issues, which are comparatively minor, the real
  149. feature was how this could be called. It prompts for two things
  150. describing what to compare, including "buffer", "file", "region",
  151. "definition", "top of kill ring" and "second in kill ring". you type
  152. a single character (B/F/R/D/c-Y/m-Y) for each such prompt. It's
  153. completely essential for comparing files. What I can't comprehend
  154. is why no one thinks this is essential in a non-versioned file system.
  155. It's important enough in a versioned file system but in a non-versioned
  156. system one is always finding "probable copies" of files all over the place
  157. and trying to understand the differences. Ready access to program
  158. controlled source compare is central to everything I do and basically
  159. wholly absent on stock hardware. Another example is when you are saving
  160. a file on the lisp machine and you find it's been written by someone else;
  161. in emacs the query just tells you of a problem--in zmacs it offers to
  162. compare the files before making you decide whether to continue saving.
  164. It's not the feature itself, though that's important, but
  165. it's the attention to detail at this fine-grained level throughout the
  166. system which is why the lisp machine is so fondly remembered.
  168. And that's my overall point. It's not just about what's missing.
  169. It's about the lack of interest in those who have created Emacs in
  170. supporting those other things. I still just use my Lisp Machine.
  171. It's right here next to my PC, and on a regular basis I just move to
  172. the other chair and edit in Zmacs. 6 years after heavy-duty
  173. development ceased on Zmacs, it still whomps the competition and makes
  174. me not care that processor speeds have gone up a zillionfold in the
  175. meantime. Others will tell you the same.
  177. I WISH I could use features like that on a fast processor. that would
  178. be great. But it isn't likely to happen soon.
  180. You can say the burden is on us old-timers to tell you what's missing or
  181. we shouldn't be whining. But I don't see it that way. I see the burden is
  182. on the victors, who have the resources and who claim their way is better,
  183. to show us that they won for good reason. We did our part for the cause.
  184. We may or may not continue to try to do things to assure the ideas aren't
  185. lost.
  187. I spend a lot of my time trying to make sure old ideas make it onto
  188. the books and don't get lost. But I'm just one person. It takes more
  189. than one person. And the task does not begin by dismissing the need
  190. to do the job.
Add Comment
Please, Sign In to add comment