It is not that the garbage collection is too slow in Lisp, he gave the reason that the amount of data that it had to go through was very large. The point of the system was to be as speedy as possible and garbage collection would slow that down no matter how much or how little data you gave it to process.
The speed of your GC does not have to be dependant on the amount of data allocated through Lisp's storage management facility. For example, many garbage collectors (such as those found in the Lisp implementations used by ITA) allow one to allocate objects in "static space" which is effectively not examined by the scavenger.
The more compelling reason to allocate objects in foreign space is mentioned at the end of paragraph 5. You can mmap() huge amounts of data read-only and have it sharable amongst an arbitrary number of user level processes.
The people I asked around the MIT AI lab didn't seem to know about it at the time, and as a Lisp machine user for half a dozen years, I never came across it in the voluminous documentation. I don't think "Lisp Lore" mentioned it either. I think if you look at how you say this was "documented", you can figure out yourself why nobody knew about it. Compare this with Smalltalk-80, which already had rich, obvious, powerful source level debugging around 1980 and presented the facility in an obvious, easy-to-use way. Overall, I think the Lisp machine had a decent development and debugging environment, but I personally wouldn't call it ground-breaking.
Bromley and Lamson's "Lisp Lore" most certainly does talk about source code debugging. If you have a copy handy, turn to the chapter on debugging. It starts on page 80. Prominently displayed information on source debugging and source locators can be found there, I promise! Symbolics published a large documentation set and provided elegant tools for finding what you want. Document Examiner's:show candidates is quite forthcoming. Did you every try using it in your search for source debugging? Lastlty, the System Index has really slick permuted indices which will point you to the very same places.
You seem to like a Smalltalk-style browser-centric debugging interfaces. Did you every try using the window debugger?
Actually, my conclusions are based on my own experience: I was a Lisp machine user for half a dozen years and a CommonLisp user for a dozen years. I tried hard to introduce CommonLisp at several research labs and companies, but eventually gave up, for the reasons that I mentioned: the implementations cost too much and writing code that was both portable and efficient was a lot of work, negating much of the productivity advantage. Furthermore, the Windows and UNIX versions of CL never really seemed to integrate well with their environment.
The reasons you cite for Lisp not meeting your needs (high prices, performance problems, lack of integration with the host environment) may have been valid complaints regarding the available Lisp systems of yesteryear, but are hardly relevant today. High performance Lisp systems which are well integrated with their host environments are readily available at all price points.
Seems like you are confirming what I'm saying: the Lisp machine did not have source level debugging until Genera 8. Whether it was hidden somewhere in the source code where your customers couldn't get at it hardly matters.
Source level debugging was documented at least as of Genera 7.0 (1986). If you wished to compile your definitions with source level debugging information you had two (documented) ways to go about doing this. The first was to compile your forms within the editor using c-m-sh-C, also known as "Compile Region Toggling Locators". The second way was to set COMPILER:*INHIBIT-USING-SOURCE-LOCATORS* to NIL, which caused everything to be compiled with source level debugging information (at which point c-m-sh-C would compile things with source locators turned off). Less elaborate forms of source level debugging were around and documented at least as of version 6.
Another interesting link about the history of Lisp and the Lisp machine is here [mit.edu], which basically reaches the same conclusion that I did.
Unfortunately, this paper has a fatal flaw: its only reference for Lisp Machine history is the Harvey Newquist book "The Brain Makers". Ironically, the authors totally messed up their bibliography entry for the Newquist book, which makes the accuracy and overall quality of the paper highly suspect.
While I found the Newquist book to be a fun read, it gets a large number of otherwise easily verifiable facts wrong. I certainly hope you did not reach your conclusions using only that book as a reference!
Slashdot Mirror
The speed of your GC does not have to be dependant on the amount of data allocated through Lisp's storage management facility. For example, many garbage collectors (such as those found in the Lisp implementations used by ITA) allow one to allocate objects in "static space" which is effectively not examined by the scavenger.
The more compelling reason to allocate objects in foreign space is mentioned at the end of paragraph 5. You can mmap() huge amounts of data read-only and have it sharable amongst an arbitrary number of user level processes.
Bromley and Lamson's "Lisp Lore" most certainly does talk about source code debugging. If you have a copy handy, turn to the chapter on debugging. It starts on page 80. Prominently displayed information on source debugging and source locators can be found there, I promise! Symbolics published a large documentation set and provided elegant tools for finding what you want. Document Examiner's :show candidates is quite forthcoming. Did you every try using it in your search for source debugging? Lastlty, the System Index has really slick permuted indices which will point you to the very same places.
You seem to like a Smalltalk-style browser-centric debugging interfaces. Did you every try using the window debugger?
The reasons you cite for Lisp not meeting your needs (high prices, performance problems, lack of integration with the host environment) may have been valid complaints regarding the available Lisp systems of yesteryear, but are hardly relevant today. High performance Lisp systems which are well integrated with their host environments are readily available at all price points.
Source level debugging was documented at least as of Genera 7.0 (1986). If you wished to compile your definitions with source level debugging information you had two (documented) ways to go about doing this. The first was to compile your forms within the editor using c-m-sh-C, also known as "Compile Region Toggling Locators". The second way was to set COMPILER:*INHIBIT-USING-SOURCE-LOCATORS* to NIL, which caused everything to be compiled with source level debugging information (at which point c-m-sh-C would compile things with source locators turned off). Less elaborate forms of source level debugging were around and documented at least as of version 6.
Unfortunately, this paper has a fatal flaw: its only reference for Lisp Machine history is the Harvey Newquist book "The Brain Makers". Ironically, the authors totally messed up their bibliography entry for the Newquist book, which makes the accuracy and overall quality of the paper highly suspect.
While I found the Newquist book to be a fun read, it gets a large number of otherwise easily verifiable facts wrong. I certainly hope you did not reach your conclusions using only that book as a reference!
Your example of "the runtime environment" not being able to "remove the costly division" from the expression is just plain wrong.
Lisp compilers are free to optimize expressions much in the same way compilers for other languages do.
Here's a real example:
(disassemble (compile (defun test (x) (* (/ x 42.0) 42.0))))
0 ENTRY: 1 REQUIRED, 0 OPTIONAL
2 PUSH-CONSTANT '42.0
4 PUSH-CONSTANT '0.023809524
6 MULTIPLY-FP|2
7 MULTIPLY SP|POP
10 RETURN-SINGLE-STACK