4 ms·
My Lisp Experiences and the Development of GNU Emacs
Transcript of Richard Stallman's Speech, 28 Oct 2002, at the International Lisp Conference
- thurn 15y agoEmacs 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.
- baddox 15y agoWho doesn't believe that?
- zmanji 15y agoSadly, 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.
- mquander 15y agoI don't think this hypothetical person is going to be a big emacs fan either.
- Jach 15y agoYou'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.
- tjarratt 15y agoI've found the "developer time is more important than machine time in 99% of cases" argument to be particular effective when preaching python to the C++ masses.
- rbanffy 15y agoNot only that, but, unless you are in that 1% , the money you'd spend on developers could buy a much beefier server.
- gaius 15y agoWell, if we're talking about scale, there is a significant difference between needing 100 servers and needing a 10,000. As in, you suddenly have far fewer choices as to where you can physically put them! At that point, suddenly, developers start to look very, very cheap next to hosting costs. If you just need to buy 2 servers instead of 1 then sure, yeah, developer time is more expensive than hardware.
- rbanffy 15y agoHow many applications you know that need 100 servers? I know of only a few that need 10...
- gaius 15y agoThe one I work on, for a start :-) A good deal more in fact... But it's not just servers. You are up against physical availability of stuff, and stuff gets exponentially more expensive as you approach the limit. A programmer who is wasteful of memory on a single box will eventually reach a point where you simply can't buy more, you will have to rewrite the app to run on more machines, for example. At the small scale, sure, programmer time is expensive. But on an industrial scale, programmers are pretty cheap compared to say "building and operating an entire new datacentre".
- tjarratt 15y agoIn general a "hypothetical person" probably isn't going to be a big fan of any one technology, platform, language, etc. There are too many choices and everything is fragmented to the point that it's hard to find any common ground between ruby developers, js / jquery developers, old school c++ hackers, bash-scripting sysadmins and even perl gurus. Emacs definitely isn't the most popular editor I've ever used though. When someone asks me why I use it, I usually give a short one minute demo where I macro a bunch of changes, show git integration, multiple buffers, and use some pre/post save hooks. Few editors come close to matching Emacs feature set.
- bitsai 15y agoI'm really bewildered by all the options for emacs-git integration. Which one is your method of choice?
- technomancy 15y agoI can't imagine using git with anything other than magit (whether from Emacs or not).
- bitsai 15y agoI'll take a look. Thanks!
- ssp 15y agoMaybe 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".
- thurn 15y agoThe 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.
- angus77 15y agoWhich would've been funny when eight megabytes was a lot of memory. Just try and buy that little memory today.
- abecedarius 15y agoYes, Emacs was bigger and sometimes slower than typical editors of the day, but no, I never saw anything like "garbage collecting for minutes". (I used it on a 486 with 8M; I think I also used it some on a 386 with 4M in console mode, but the old memory's getting fuzzy.)
- pjscott 15y agoAccording to the GNU Emacs docs, it can also stand for "Emacs Makes A Computer Slow", "Eventually Mallocs All Computer Storage", or (my favorite) "Escape Meta Alt Control Shift".
- jedbrown 15y agoMy 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.
- winestock 15y agoAgreed on the responsiveness issue. You don't even have to open hundreds of buffers, either. Emacs has given me embarrassing pauses while auto-saving a text file only a few kilobytes in size. Emacs will also make the text flicker as it redisplays the buffer every few minutes.
- technomancy 15y agoI use Emacs all day every day and have never experienced anything like this. I suspect the problem is specific to CEDET.
- 15y ago
- tjarratt 15y agoI'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.
- swolchok 15y agonode.js isn't interpreted; it uses V8, which is a JIT.
- technomancy 15y agoEmacs Lisp is also typically byte-compiled.
- mahmud 15y agoJIT != byte compilation.
- dkarl 15y agoNo matter how the underlying implementation works, programming in neither Emacs Lisp nor Javascript could be described as "sticking close to machine code the whole time," as the original comment stated.
- rawsyntax 15y agoI find that emacs ruby-mode slows to a crawl when editing a 6000 line ruby file. Now I realize the file is way too long ( these things take time to fix / refactor ), any tips on getting it to be more responsive?
- deleted 15y ago[deleted]