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 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.
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.
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.
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".
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.
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.)
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?
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.
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.
It's effective, but less-so when the audience hasn't programmed anything Big before. If you've only done programming in school, and all of your C++ assignments take anywhere from 1 to 12 hours to complete, it's hard to see the dev time benefits.
Well, 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.
The 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".
If you are in the 10+ server league, you already are in that 1% where code efficiency and performance become more important than iteration speed or ease of development. In fact, it would be interesting to map where this transition occurs ;-)
And computers are cheap, regardless of how many you have. You say a datacenter with 50K servers is expensive, but imagine how bad would it be to maintain a building with 50K programmers...
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.
Real Python people are totally pragmatic about this - if you need performance, drop into C for critical routines and use Python to glue it all together. This is how NumPy works, you totally can do hard-core number crunching in Python and never need to actually know that it's C or FORTRAN under the hood!
Other language communities make a point of being self-contained and consider it a failure if you need to use a native method, but as ever, it's about the right tool for the job.
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++.
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.
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.
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.
