Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Lisp Experiences and the Development of GNU Emacs

gnu.org

Post reply on HN
Print view View original

21–30 of 42 posts

Re: My Lisp Experiences and the Development of GNU Emacs

#21

Post by pjscott »

ssp wrote: post #5
thurn wrote: 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".

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

Re: My Lisp Experiences and the Development of GNU Emacs

#22

Post by rbanffy »

tjarratt wrote: post #12
Jach wrote: post #8

Earlier quoted context omitted.

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.

Not only that, but, unless you are in that 1% , the money you'd spend on developers could buy a much beefier server.

Re: My Lisp Experiences and the Development of GNU Emacs

#23

Post by [deleted] »

rawsyntax wrote: post #14
thurn wrote: 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?

[deleted]

Re: My Lisp Experiences and the Development of GNU Emacs

#24

Post by dkarl »

_cbsz wrote: post #13
tjarratt wrote: post #10

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.

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

Re: My Lisp Experiences and the Development of GNU Emacs

#25

Post by winestock »

jedbrown wrote: post #9
thurn wrote: 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.

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

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

Re: My Lisp Experiences and the Development of GNU Emacs

#26

Post by prodigal_erik »

tjarratt wrote: post #12
Jach wrote: post #8

Earlier quoted context omitted.

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.

Even if 90% of startups fail, surely more than 10% of the survivors will have Twitter-esque scaling problems if all their prototypes were on platforms with severe performance drawbacks.

Re: My Lisp Experiences and the Development of GNU Emacs

#27

Post by bitsai »

tjarratt wrote: post #11
mquander wrote: post #7

Earlier quoted context omitted.

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. W…

I'm really bewildered by all the options for emacs-git integration. Which one is your method of choice?

Re: My Lisp Experiences and the Development of GNU Emacs

#28

Post by technomancy »

jedbrown wrote: post #9
thurn wrote: 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.

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

I use Emacs all day every day and have never experienced anything like this. I suspect the problem is specific to CEDET.

Re: My Lisp Experiences and the Development of GNU Emacs

#29

Post by technomancy »

bitsai wrote: post #27
tjarratt wrote: post #11

Earlier quoted context omitted.

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. W…

I'm really bewildered by all the options for emacs-git integration. Which one is your method of choice?

I can't imagine using git with anything other than magit (whether from Emacs or not).

Re: My Lisp Experiences and the Development of GNU Emacs

#30

Post by copper »

technomancy wrote: post #28
jedbrown wrote: post #9

Earlier quoted context omitted.

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

I use Emacs all day every day and have never experienced anything like this. I suspect the problem is specific to CEDET.

It's what happens if you use cedet/ecb on lots of code. I like the code completion and other features they give me, but it is just too slow to keep on always.
Post reply on HN