help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Issues with emacs (was Emacs users a dying breed?)


From: Ludwig, Mark
Subject: RE: Issues with emacs (was Emacs users a dying breed?)
Date: Mon, 25 Jun 2012 19:23:19 +0000

> From: Eric Abrahamsen
> Sent: Sunday, June 24, 2012 6:38 AM
> To: help-gnu-emacs@gnu.org
> Subject: Re: Issues with emacs (was Emacs users a dying breed?)
> 
> On Sun, Jun 24 2012, Tom wrote:
> 
> > Bastien <bzg <at> gnu.org> writes:
> >
> >>
> >> The good news is that, whether Emacs users are a dying breed
> >> or not, the only remedy to this hypothetical issue is to have
> >> more Emacs developers.
> >>
> >
> > But how to have more developers. I see 3 possibilites:
> >
> > 1. Motivate more users to be volunteer developers? Any idea how
> > to do that?
> 
> One possibility: if a pure-Lisp implementation of Emacs became the
> "main" implementation, I wonder if many Elisp-gurus who aren't
> particularly enthusiastic about C programming would be encouraged to
> expand their hacking into the Emacs basics.
> 
> If the line between programming Emacs packages and programming Emacs
> guts were blurred or erased altogether, I'll bet you'd get a lot more
> people able and willing to contribute work on fundamentals like the
> display engine or multi-threading.

Perhaps in the abstract this is a good idea, but it's not at all clear to me 
that you want a bigger crowd of people working on either of those two areas, in 
particular.  They're very tender areas, and it's likely that a worker needs a 
lot of context in order to successfully modify these things.  Learning the 
context takes time and I believe our do-everything-faster culture does not 
particularly reward the slow learning processes necessary in order to learn 
complex programming contexts such as these.  Some of the context comes from bug 
reports.

(IMHO, in general, far too many people attempt to write or modify 
multi-threading code than are actually competent to do so.  The hardware and 
software complexities involved in getting robust memory ordering across 
processors with good performance are simply beyond the average programmer....)

Cheers,

Mark

Ob.Help: 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]