Re: Why is Elisp slow?

[Paul W. Rankin]

On Sun, May 05 2019, Ergus wrote:
> I totally agree with the complexity of mixing languages; but if we 
> look around it is very difficult to attract new users and developers 
> if they need to learn a new (old fashion) language only for Emacs (as 
> I have been doing the last months). New programmers generations only 
> know python and some C-like languages but specially OOP and maybe is 
> the moment to think a bit in the future of the project more than in 
> the past. Even if that implies taking some risks and make hard 
> desitions. Just give a look how popular are sublime text or athom, 
> that compared to Emacs those are kid toys.
>
> So at some point it will be needed to make this desitions because the 
> old developers will not live forever. I see the beauty of Lisp, but I 
> am talking more about a human issue here, that is more critical for 
> Emacs right now and for the future.

I don't understand this sentiment. Is there some emergency in Emacs 
development that I'm unaware of? Development seems faster and stronger 
than it ever has in the decade or so I've been using Emacs -- there's a 
new major release every year or so, and with the addition of package.el 
there's the introduction of third-party package archives and the 
explosion that is MELPA.

The possibility of the current Emacs developers all dying out is not 
something anyone needs to worry about for at least another 30-40 years, 
and I'm pretty sure we (the human race) will have vastly different 
concerns by then. But even if we reach a point where there is no one 
left maintaining/developing/using Emacs, it's open source code... 
someone will discover it and if they find it useful or interesting, they 
will continue developing it. Open source code can never really die.

Where does this fear come from that an open source project will die if 
it doesn't keep changing?

> For the developers it is also easier to join to those projects because 
> they are hosted on Github/gitlab with a more familiar workflow and 
> interface, no copyright procedure, no mailing list.... and everything 
> in the same please and integrate with a fork based workflow. You can 
> see where I'm going right?

If a possible contributor has cloned a project repository to their own 
machine and has made some changes, the fork-based workflow requires that 
they: create an account at the origin project's GitHub or GitLab (or the 
project's GitLab instance), create a forked repository there, add the 
fork as a remote on their machine, push the changes, then open a pull 
request.

Once you use a git send-email workflow, this fork-based workflow will 
seem convoluted and unnecessarily centralised. All a contributor need do 
is clone the project repository, commit some changes then run:

   git send-email HEAD^

And send the email to the project's owner/mailing list. No account 
creation necessary. Check out:

   https://git-send-email.io/

Yes the copyright assignment procedure is a deterrent to contributing to 
Emacs/ELPA; this discussion is probably for another thread.

--
https://www.paulwrankin.com