Live data from Hacker News

My Lisp Experiences and the Development of GNU Emacs

gnu.org

31–40 of 42 posts

Re: My Lisp Experiences and the Development of GNU Emacs

#31
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.

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.

Re: My Lisp Experiences and the Development of GNU Emacs

#32
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.

That is a very dangerous myth, IMHO. Sure, sometimes it's true. But when it's not, you're up the creek without a paddle.

Re: My Lisp Experiences and the Development of GNU Emacs

#33
post #22

Earlier quoted context omitted.

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.

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.

Re: My Lisp Experiences and the Development of GNU Emacs

#34
post #33
post #22

Earlier quoted context omitted.

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

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.

How many applications you know that need 100 servers?

I know of only a few that need 10...

Re: My Lisp Experiences and the Development of GNU Emacs

#35
post #34
post #33

Earlier quoted context omitted.

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.

How many applications you know that need 100 servers? I know of only a few that need 10...

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

Re: My Lisp Experiences and the Development of GNU Emacs

#36
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…

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.

It's probably irrelevant, but maybe http://www.method-combination.net/blog/archives/2011/03/11/s... will help

Re: My Lisp Experiences and the Development of GNU Emacs

#37
post #18
post #16

Earlier quoted context omitted.

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

Got any advice for someone trying to revive a bunch of Panasonic Toughbooks (CF25)?

EDIT: that is not "don't run EMacs on it", that is.. ;)

Re: My Lisp Experiences and the Development of GNU Emacs

#38
post #27

Earlier quoted context omitted.

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

I'll take a look. Thanks!

Re: My Lisp Experiences and the Development of GNU Emacs

#39
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.

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.

Re: My Lisp Experiences and the Development of GNU Emacs

#40
post #35
post #34

Earlier quoted context omitted.

How many applications you know that need 100 servers? I know of only a few that need 10...

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

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

Post reply on HN