Re: Emacs contributions, C and Lisp

[Eli Zaretskii]

> From: chad <address@hidden>
> Date: Tue, 18 Feb 2014 21:33:26 -0800
> Cc: emacs <address@hidden>
> 
> To some degree, but (my impression is that) Emacs stops a lot of
> changes at the need for support on more platforms than the submitter
> can easily develop on.

Can you give a couple of examples?

In any case, this is mainly relevant to the C level; on the Lisp
level, the code is mostly platform independent.

> > Which projects don’t?
> 
> Most software projects today are much smaller, more nimble, and
> piecemeal-clockwork than emacs. Emacs was built in a heavily
> monolithic era, and continues with most of that lineage. Far more
> software projects today are assembled from many interlocking pieces
> of libraries, middleware, and plugin code. Again, there are good
> reasons for this, but it has a cost, and much of that cost is
> expressed as a high barrier to entry.

But then it's not very useful to talk about this, because obviously
Emacs will never become as small as those projects, or somehow will be
divided into many almost unrelated sub-projects.  There's nothing we
can do about Emacs being a large and complex package.

> Another thing that hits Emacs: people working on changing or extending
> Eclipse do it IN java, which is the same language they use Eclipse
> FOR. While there are surely Emacs developers using Emacs to develop
> Emacs Lisp, theyre doing so mostly just for Emacs, not for anything
> else; this internal focus shows in the results.

Not sure what you want to say here.  Is it that most people don't know
Lisp and need to learn it?

> Emacs own C code is highly idiosyncratic.

??? When did you last look at the C sources of a comparable project,
like GDB or GCC?  Or Guile, for that matter?

> Again, Im aware that there are good reasons for all of these things
> to be true, but each of them makes it harder for people to make
> significant contributions to Emacs, which is the topic at hand.

It's not useful, IMO, to discuss circumstances we cannot possibly
change.  We need to make contributing as simple as possible, but no
simpler.  Finding that golden path is the challenge that is worth
discussing.