From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: seq.el and the complexity of Emacs Lisp. Date: Tue, 07 Nov 2023 11:14:07 +0100 Message-ID: <87a5rplvkg.fsf@dataswamp.org> References: <83pm0n2h5j.fsf@gnu.org> <42480.5172298633$1699275087@news.gmane.org> <87edh2fu39.fsf@dataswamp.org> <9c1e5ef2-f3a5-4bd1-927e-6d9679023402@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14524"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:sSeWDwInryzE12rsXDp13dC3xrA= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 07 12:54:31 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r0Kf9-0003Z1-4N for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Nov 2023 12:54:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0Kes-0000P7-F8; Tue, 07 Nov 2023 06:54:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0J6F-0005ev-81 for emacs-devel@gnu.org; Tue, 07 Nov 2023 05:14:23 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0J6D-00033h-D4 for emacs-devel@gnu.org; Tue, 07 Nov 2023 05:14:23 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r0J69-0002SL-9T for emacs-devel@gnu.org; Tue, 07 Nov 2023 11:14:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 07 Nov 2023 06:54:11 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312298 Archived-At: Harald Judt wrote: >>>>> Saying lets just drop these in a sec to all package >>>>> authors seems overreaching. >>>> >>>> Richard's question was about use of cl-lib in the Emacs >>>> tree, it will not (and cannot) affect >>>> third-party packages. >>> >>> He also mentioned about ELPA. Even if it's just the Emacs >>> tree it does seem overreaching unless there's >>> a direct benefit. >> >> On the whole, changing code that works, for that to make >> sense one must have a distinct improvement in mind, that is >> almost beyond discussion, otherwise it isn't worth the >> effort to do it, with everything negative and unexpected >> that can follow - in my experience. > > That seems to be a common but unfortunate practice nowadays, > that you should not touch code that is working, especially > rooted in corporate environments. Every improvement to the > code will make it easier to maintain in the long term, > fighting bit-rot and inconsistencies. If you touch it and it > fails, you simply fix it, there is nothing preventing you > from making changes to the code again. Fighting bit-rot and inconsistencies is okay if those are small, easy and uniform to fix, and one can see a clear benefit of doing so (be it small in size as well). But cl-lib is huge, any action to reduce its influence will be an equally huge effort - an effort that will seldom look the same twice - and, worse, can anyone tell for sure what the benefit would be again? Code that is easier to maintain? Why exactly, and how do we even know that? What are we going to replace cl-1, cl-2, ..., cl-n with to get what kind of advantage-1, advantage-2, ..., advantage-n exactly? Can anyone tell, really? No, this whole case against cl-lib doesn't add up, sorry. -- underground experts united https://dataswamp.org/~incal