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: Adding a generic mathematical library Date: Thu, 25 Jul 2024 16:24:45 +0200 Message-ID: <87msm5h7ma.fsf@dataswamp.org> References: <172176485988.7.10588738866494480552.387245090@slmails.com> <87le1qgl2n.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="16136"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:1b+iZiLW6A4BN+qqDqR/eJFLYHk= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 25 17:07:26 2024 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 1sX03x-00042R-69 for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Jul 2024 17:07:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sX03F-0007G8-HG; Thu, 25 Jul 2024 11:06:41 -0400 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 1sWzP2-00077G-M0 for emacs-devel@gnu.org; Thu, 25 Jul 2024 10:25:08 -0400 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 1sWzP0-0002VG-QG for emacs-devel@gnu.org; Thu, 25 Jul 2024 10:25:08 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1sWzOx-0004k2-MX for emacs-devel@gnu.org; Thu, 25 Jul 2024 16:25:03 +0200 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: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 25 Jul 2024 11:06:39 -0400 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:322088 Archived-At: Christopher Dimech wrote: >> Calc was brought into the discussion as a way of opposing >> the idea of a library. To say, we don't need it, because we >> already have it. > > Incorrect, we generally do not accept new packages that > substantially overlap with existing GNU packages. That means the more you do this "program as a library", the less you can have a common library for many programs. So the solution to the problem cannot be done, because of what is the result of not having it arranged soundly in the first place. When it would have been super-easy. "Here, here is math.el and string.el, use it and put new stuff in it!" Instead, that stuff has ended up all over Emacs. But it is what it is, anyone thinking that model is good, go ahead and think so. "We don't do generic libraries. We think it is normal that a program that has nothing to do with ERC, Gnus and Calc to do generic operations on strings and numbers require files that are part of all these programs." Instead of blaming why the problem cannot be fixed on others who have nothing to do with that idea. > The procedure is for GNU to have a given package to do > a given job, and people in that area to contribute to and > improve that package, working together, instead of having > many packages that each do different parts of a job, each > developed on its own. In practice "program as a library" means the opposite. Every program does a little of everything. Instead of adding to the common library, what is missing is added to the program. When something is needed by another program, instead of bringing it from library, it brings in the first program. Until there is something additionally needed, then that is added, again not to the library but to the second program. And so on. > Is there a good reason why an association with them is > so terrible? Oh, absolutely not! Like I said, it is like this all over the place. Here, check out the string library! Only those files are all over Emacs. (shortdoc-display-group "string") -- underground experts united https://dataswamp.org/~incal