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 14:50:56 +0100 Message-ID: <87o7g5k6yn.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> <87a5rplvkg.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13762"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:eVTxikCxCgAk/wgu5W0NNtSDTX8= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 07 15:07:33 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 1r0Mjt-0003Ms-5e for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Nov 2023 15:07:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0Miv-0001jz-GF; Tue, 07 Nov 2023 09:06:33 -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 1r0MU5-0005xt-0M for emacs-devel@gnu.org; Tue, 07 Nov 2023 08:51:14 -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 1r0MU3-00005G-19 for emacs-devel@gnu.org; Tue, 07 Nov 2023 08:51:12 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r0MTz-0000k7-JC for emacs-devel@gnu.org; Tue, 07 Nov 2023 14:51:07 +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 09:06:32 -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:312309 Archived-At: Harald Judt wrote: > My response was targeted more at the general denial to code > changes, not about this discussion about cl-lib. > Your assumption that every change needs to be driven by > benefit seems a bit short-sighted to me. It is probably good > enough when you want to build something fast without having > to care about it much later. Maybe it holds when you lack > time because then not wasting time is a priority. But if you > want to build something for long-term use, it might not be > an optimal solution. Having to depend on immediate benefits > to change anything also loses importance when time is not > that much of a priority. Well, now we are getting into the whole "revolution vs evolution" discussion. It is true that you can't expect to achieve something truly original and great by endlessly piling up very small incremental gains. But the great leaps are made more easily if you have those incremental gains already. And it is often indicative that a great leap is truly great, if the way to it are big and small incremental gains. > If cl-lib is huge, then one should ask, why has it grown > that huge? Is it just a badly documented one-pot of several > ideas thrown together instead of someone doing a library > using careful planning? Wouldn't it have been better then to > replace those functions with something better? Could the > situation be improved by revising the cl-lib documentation, > or splitting up the library and progressively replacing it > with something better? I think a lot of people have had a very positive experience from it, and this is the reason for its proliferation. But of course, incremental gains and great leaps are welcome there as well :) -- underground experts united https://dataswamp.org/~incal