Re: Is Elisp really that slow?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 16 May 2019 18:14:08 +0200
> From: Ergus <spacibba@aol.com>
> Cc: help-gnu-emacs@gnu.org
> 
> >> We are far from becoming a toxic community, but new/different ideas are
> >> not really very welcome and sometimes the arguments are like "it has
> >> always been like that", "old users don't want that change".
> >
> >Really?  You've just went through a process of proposing and
> >implementing a new feature -- did you feel your idea was "not really
> >welcome"?
> >
> Actually fill-column-indicator was something that many people were using
> (with the package) but it doesn't affect the global behavior at
> all.

It's a reimplementation in core of a popular feature.  I think you are
wrong: I'm sure quite a few people will be happy to see it alive and
much faster than the Lisp implementation that is no longer maintained.

> But when we mention (propose, suggest) to do any change in the defaults
> or remove obsolete functionalities to promote new ones, or change old
> features to add more modern ones... the mailing list starts becoming
> crazy.

Emacs is an old program, with users who stay with it for 25 and more
years.  Changing old defaults or making other incompatible changes
definitely annoys at least some of those users, especially since quite
a few people don't track the development, and don't see the changes
until years later, sometimes even after skipping several releases
in-between.  This isn't theory, this is our (and my personal) actual
experience from watching Emacs development.  When someone comes up and
asks why we made a certain change in how Emacs worked for decades, we
should have a good reason, and if we don't, we shouldn't make the
change "just because we can".  That's the price of maintaining and
developing an old and stable program.

Personally, I wish people would invest much more time and efforts in
adding new features, and would stop futzing with existing features.
For starters, the former is much more useful for our users than the
latter.  Also, I see many times how a change in existing code to make
some minor improvement introduces bugs, which sometimes are more
significant than the "fixed" problem -- this is expected in a complex
stable program, and is a clear sign that changes of existing code long
since entered the area which engineers call "the limit cycle" --
oscillations that don't converge, i.e. the overall code quality is
quasi-constant.  IOW, we are wasting our own resources for little or
no gain.

> Just give a look how many good packages are in melpa, but not in elpa

If you are saying that those packages are in MELPA because they were
rejected to be included in Emacs or ELPA, then I'd be very surprised
to learn that this is true.  I think the vast majority of those
packages started up with MELPA and their developers never tried to
submit the packages to be included in Emacs.