[Top][All Lists]

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

Re: Why is Elisp slow?

From: Paul W. Rankin
Subject: Re: Why is Elisp slow?
Date: Sun, 05 May 2019 15:25:59 +1000
User-agent: mu4e 1.2.0; emacs 26.2

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:

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


reply via email to

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