From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg via help-gnu-emacs Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Sat, 25 May 2019 07:14:16 +0200 Message-ID: <86mujbdsk7.fsf@zoho.eu> References: <20190514235412.kncazq45szlum2gr@Ergus> <83v9yb92c7.fsf@gnu.org> <878sv7sp3r.fsf@telefonica.net> <83r28z8zl9.fsf@gnu.org> <20190515210924.sijzy6mnpgzkt4gm@Ergus> <83ftpecwu1.fsf@gnu.org> <20190516161408.4dov3dwk5h4yoizn@Ergus> <838sv6cmwt.fsf@gnu.org> Reply-To: Emanuel Berg Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="177780"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat May 25 07:16:39 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hUP2q-000k61-Ez for geh-help-gnu-emacs@m.gmane.org; Sat, 25 May 2019 07:16:36 +0200 Original-Received: from localhost ([127.0.0.1]:36476 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUP2o-0007QJ-JA for geh-help-gnu-emacs@m.gmane.org; Sat, 25 May 2019 01:16:34 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hUP2W-0007Ni-MD for help-gnu-emacs@gnu.org; Sat, 25 May 2019 01:16:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hUP0m-00089t-Pq for help-gnu-emacs@gnu.org; Sat, 25 May 2019 01:14:29 -0400 Original-Received: from [195.159.176.226] (port=53690 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hUP0m-00089Q-Iu for help-gnu-emacs@gnu.org; Sat, 25 May 2019 01:14:28 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hUP0k-000hmB-D0 for help-gnu-emacs@gnu.org; Sat, 25 May 2019 07:14:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Cancel-Lock: sha1:S0E8wsJAy4yo2TdV0AmX6/728hE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120629 Archived-At: 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