Live data from Hacker News

My Lisp Experiences and the Development of GNU Emacs

gnu.org

11–20 of 42 posts

Re: My Lisp Experiences and the Development of GNU Emacs

#11
post #7
post #4

Earlier 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.

In 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.

Re: My Lisp Experiences and the Development of GNU Emacs

#12
post #8
post #7

Earlier quoted context omitted.

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.

I'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.

Re: My Lisp Experiences and the Development of GNU Emacs

#13
post #2

Emacs 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 lis…

node.js isn't interpreted; it uses V8, which is a JIT.

Re: My Lisp Experiences and the Development of GNU Emacs

#14
post #2

Emacs 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 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?

Re: My Lisp Experiences and the Development of GNU Emacs

#15
post #13

Earlier quoted context omitted.

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 lis…

node.js isn't interpreted; it uses V8, which is a JIT.

Emacs Lisp is also typically byte-compiled.

Re: My Lisp Experiences and the Development of GNU Emacs

#16
post #5
post #2

Emacs 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".

Which would've been funny when eight megabytes was a lot of memory. Just try and buy that little memory today.

Re: My Lisp Experiences and the Development of GNU Emacs

#18
post #16
post #5

Earlier quoted context omitted.

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".

Which would've been funny when eight megabytes was a lot of memory. Just try and buy that little memory today.

If you manage to do it, it's ridiculously expensive. Believe me - I restore interesting computers from the 80's and early 90's

Re: My Lisp Experiences and the Development of GNU Emacs

#19
post #5
post #2

Emacs 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".

Yes, 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.)

Re: My Lisp Experiences and the Development of GNU Emacs

#20
post #8
post #7

Earlier quoted context omitted.

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.

In my experience, most Java zealots use Eclipse. Emacs folks typically are more hands-on people. The C++ crowd I know is more or less split between Emacs and Visual C++.
Post reply on HN