Transcript of Richard Stallman's Speech, 28 Oct 2002, at the International Lisp Conference
My Lisp Experiences and the Development of GNU Emacs
1–10 of 42 posts
Re: My Lisp Experiences and the Development of GNU Emacs
#2Emacs is the first and probably best proof that you can write fast and responsive software without needing to stick close to machine code the whole time. It's a compelling counterexample to those who don't believe you can write "real" software in Python or Ruby.
Re: My Lisp Experiences and the Development of GNU Emacs
#3Emacs is the first and probably best proof that you can write fast and responsive software without needing to stick close to machine code the whole time. It's a compelling counterexample to those who don't believe you can write "real" software in Python or Ruby.
Who doesn't believe that?
Re: My Lisp Experiences and the Development of GNU Emacs
#4Emacs is the first and probably best proof that you can write fast and responsive software without needing to stick close to machine code the whole time. It's a compelling counterexample to those who don't believe you can write "real" software in Python or Ruby.
Who doesn't believe that?
Sadly, many people don't. Try bringing up the idea of writing a large program in Ruby or Python and they'll balk at you saying that the languages are too slow. They will insist on using C++ or Java.
Re: My Lisp Experiences and the Development of GNU Emacs
#5Emacs is the first and probably best proof that you can write fast and responsive software without needing to stick close to machine code the whole time. It's a compelling counterexample to those who don't believe you can write "real" software in Python or Ruby.
Maybe I'm missing the joke, but Emacs was famous for bringing multi-megabyte machines to their knees and garbage collecting for minutes. The joke was that emacs stood for "eight megabytes and constantly swapping".
Re: My Lisp Experiences and the Development of GNU Emacs
#6Emacs is the first and probably best proof that you can write fast and responsive software without needing to stick close to machine code the whole time. It's a compelling counterexample to those who don't believe you can write "real" software in Python or Ruby.
Maybe I'm missing the joke, but Emacs was famous for bringing multi-megabyte machines to their knees and garbage collecting for minutes. The joke was that emacs stood for "eight megabytes and constantly swapping".
The joke was popular among the more elitist vi users, sure, but Emacs was a widely used and useful piece of software 20 years ago on processors a dozen times slower than today's. That's a success story in my books.
Re: My Lisp Experiences and the Development of GNU Emacs
#7Earlier quoted context omitted.
Who doesn't believe that?
Sadly, many people don't. Try bringing up the idea of writing a large program in Ruby or Python and they'll balk at you saying that the languages are too slow. They will insist on using C++ or Java.
I don't think this hypothetical person is going to be a big emacs fan either.
Re: My Lisp Experiences and the Development of GNU Emacs
#8Earlier quoted context omitted.
Sadly, many people don't. Try bringing up the idea of writing a large program in Ruby or Python and they'll balk at you saying that the languages are too slow. They will insist on using C++ or Java.
I don't think this hypothetical person is going to be a big emacs fan either.
You'd be surprised. I think it's basically what they're raised on. I recently gave an info talk at my old high school CS class where they use Linux, emacs, and learn C++ and (in the AP class) Java. One student in particular was anti-Python due to speed issues but it wasn't too hard to talk him down after examples and explaining ways to speed it up.
Re: My Lisp Experiences and the Development of GNU Emacs
#9Emacs is the first and probably best proof that you can write fast and responsive software without needing to stick close to machine code the whole time. It's a compelling counterexample to those who don't believe you can write "real" software in Python or Ruby.
My biggest problem with Emacs today is responsiveness. This is partly due to lack of threading, partly due to slow execution of Elisp code, and partly due to poor data structures/database use in the back end (e.g. for maintaining indexes). I have to throttle semantic analysis from CEDET just to have a usable system and I avoid other features because they just take too long to run.
My Emacs session has been running for two weeks and I have 560 open buffers, which amounts to a memory usage of 620 MB. I don't think it's unreasonable for most every interactive operation to be instant.
I don't blame Lisp for the slowness, except insofar as the language promotes the use of data structures like simple lists that eventually create bottlenecks, and that the Elisp implementation is not very fast compared to something like SBCL.
Re: My Lisp Experiences and the Development of GNU Emacs
#10Emacs is the first and probably best proof that you can write fast and responsive software without needing to stick close to machine code the whole time. It's a compelling counterexample to those who don't believe you can write "real" software in Python or Ruby.
I'll see your emacs as "best proof" and raise you node.js - sure it's C++ underneath, but few people are going to argue that interpreted javascript is "close to machine code". For some tasks, elisp is a clunky and slower than writing a shell script or small python/ruby/javascript process to do the same work. I don't even want to mention the horror that is finding correct documentation for a given version of emacs lisp compared to any other software or language.
disclosure: I'm currently writing a small node server in emacs. I'm happy with both as they are very responsive, but emacs does chug occasionally like a bro at a frat house.