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: we need *modularity* [last problem] (was: Re: as for Calc and the math library) Date: Fri, 16 Aug 2024 08:17:51 +0200 Message-ID: <87frr53sa8.fsf_-_@dataswamp.org> References: <864j7qhup6.fsf@gnu.org> <87a5hi0yts.fsf@valhala.localdomain> <86y152ge0b.fsf@gnu.org> <86jzgjfwqp.fsf@gnu.org> <87sev78arx.fsf@gmail.com> <86le0z89u1.fsf@gnu.org> <87o75v87n1.fsf@gmail.com> <86frr786k7.fsf@gnu.org> <861q2q8e18.fsf@gnu.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="25047"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:NY7Su/jOnJNbSAbL+zIvf/NXjXU= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 16 08:45:15 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 1seqi3-0006Lb-L3 for ged-emacs-devel@m.gmane-mx.org; Fri, 16 Aug 2024 08:45:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1seqhL-0000wH-KF; Fri, 16 Aug 2024 02:44:31 -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 1seqHo-00082A-Fr for emacs-devel@gnu.org; Fri, 16 Aug 2024 02:18: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 1seqHm-0003w5-C2 for emacs-devel@gnu.org; Fri, 16 Aug 2024 02:18:08 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1seqHj-0001Go-GV for emacs-devel@gnu.org; Fri, 16 Aug 2024 08:18: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: -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: Fri, 16 Aug 2024 02:44:29 -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:322797 Archived-At: arthur miller wrote: > I have seen your previous answers to others, and I do > understand the point you make, but I think the argument > fails because a module can be just a proxy to > a non-free library. Emacs is notoriously not modular. Everything is everywhere, you seem to have everything but if fact you have nothing. There is so much stuff you can't find the basics stuff that isn't there. Here take a look: what does this name say? cl--defalias Ah, that's a local function in the Common Lisp package, right? Well, YES, but ... It is actually an Elisp defun. And that prefix isn't really a package qualifier, it is just a convention, part of the name. And the double dash, likewise just a convention, we don't have package modularity or any of that kind of data hiding, abstraction, encapsulation ... what is it more called? Well, modularity! In Emacs everything is intermixed, Elisp-Emacs, non-interactive/interactive, data/data processing/the interface (buffer, buffer, and buffer), what is a file, what is a package, what is a library, and what is a program - no one can tell. Emacs Lisp isn't is fun, but absolutely not any kind of powerhouse. It is inconsistent in itself and on top of that all those zillion interfaces, cl-, seq-, slime- (yes, had to use that today, for `slime-transpose-lists'). It is pretty fast to get something going but complexity skyrockets. What we should do, in general: modularity! clear divisions, in particular, libraries for everything, including those that provide basic stuff in a complete and consistent way. We should get real package modularity, transform the prefixes into real package qualifiers, and throw away the ugly local ones. With Elisp, optimize everything for development speed and convenience, have consistent interfaces as much as possible, acknowledge that Elisp was underpowered, which is why all the interfaces came, now, core Elisp and the interfaces should make peace, one should identify what it is exactly, what are the to 10 things that people use with cl-, pcase-, seq- etc, and bring them into a new core Elisp, and the few CL experts can still use all the rest. Now, with native compilation we have speed - we have power with the interfaces if one could harvest it, which one currently - well, it is very slow and difficult, anyway - the very, very last spet into maturity and getting out of the Elisp ghetto (and getting visitors!) are modularity, modern software principles - by modularity I mean real modularity, based on technology - not silly conventions - I forgot where I was - the last step is modularity in general, and libraries in particular. Clear cut interfaces. Get away with the ugly prefixes and error--prone conventions that don't even do anything. Elisp 3.0! \o/ PS. This is the problem. This series is completed, I said I would write 10, I wrote 4. Here are the other parts. It is all based on the same theme. Modularity, consistency, libraries, modern software practises. https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00154.html https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00380.html https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00388.html PPS. So who is working on real modularity based on the package with real public and local functions as we speak? I know there are always some guy - at least - working on such a basic idea. I know some way. And I know some day. -- underground experts united https://dataswamp.org/~incal