Re: Is Elisp really that slow?

[Emanuel Berg via help-gnu-emacs <help-gnu-emacs@gnu.org>]

Eli Zaretskii wrote:

> 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.

This is all true, not just with Emacs but
with everything.

Fiddle with details up to a point, then stop.

Obey tradition. What has worked will work and
there is no reason to fix it for the sake of
it, for esthetical reasons or to make it
more modern. If it ain't broke etc.

If you want to be a radical, do new stuff and
add them next to the old stuff. Then have
users, including yourself, decide what to use
and when.

This is so much more the right and easy thing
to do in a computer program!

While in a bike repair shop for example, there
are almost always practical considerations that
are much worse to deal with. If you acquire
a new machine or piece of equipment (a bench
grinder, truing stand, or whatever), you can't
just put it at the optimal place because there
are already a bunch of other stuff there!
The new stuff may be better in 9/10 cases, but
what about the 10th case? Also, the old stuff,
everyone knows how to use, so for some time, it
will still be better in practice!

With a computer program, you don't have to deal
with such issues. Just add more great stuff
whenever possible, w/o removing any of the old
that 1) works and 2) is useful!

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal