From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: ams@gnu.org (Alfred M. Szmidt) Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Sat, 09 May 2020 04:35:41 -0400 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87wo5mc04t.fsf@fastmail.fm> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="73175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joostkremers@fastmail.fm, rms@gnu.org, emacs-devel@gnu.org To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 10:36:12 2020 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 1jXKxv-000Iv8-88 for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 10:36:11 +0200 Original-Received: from localhost ([::1]:34232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXKxt-0005v9-Ri for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 04:36:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47210) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXKxT-0005Qu-2N for emacs-devel@gnu.org; Sat, 09 May 2020 04:35:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47664) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXKxS-0006jJ-Os; Sat, 09 May 2020 04:35:42 -0400 Original-Received: from ams by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jXKxR-0002cP-7L; Sat, 09 May 2020 04:35:41 -0400 In-reply-to: (message from Philippe Vaucher on Sat, 9 May 2020 09:38:04 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:249376 Archived-At: > > But you just described what dash does. ;-) It is just a collection > > of list-handling functions such as they exist in modern functional > > programming languages. If you're used to thinking in this paradigm > > and then come (back) to Emacs Lisp, it feels like a hopelessly > > clunky language. `dash.el` was written to remedy this. > > That sounds like they could be useful facilities. Since they are real > features, not mere aliases and trivialities, they would not have the > main flaw of s.el. Richard, I think this is a good opportunity for you to actually go and really see what dash.el is and also what s.el is, maybe even code a little with them. Your comments really make it look like you vaguely understand what they are about. I'm sorry if that's not the case. As someone who has gone through both, I still do not know what to use dash.el for, I still don't see what s.el adds other than some more Scheme like alises for the string functions in Emacs. Insisting on everyone to just sit down and understand 100K of code (that is the size of dash.el), and then on top of it trying to find something to use it for won't move the discussion forward. Except if I missed it, here are the questions I didn't see an answer to: - As far as I know you are the only one who objected strongly against s.el in ELPA (others please voice your opinion if you think like Richard). I as a Emacs user would think s.el is a bad addition to ELPA -- it doesn't add anything special, and makes code harder to read if people use such constructs in the form that they are now, encouraging people to use s-titleize instead of capitalize is going backwards, not forwards. I haven't seen anyone objecting from adding some of the more complicated functions and making them follow a more Emacs-y form, or even on a case-by-case basis renaming some string functions to make more sense. So why this forceful insistance of adding a s.el? Why not try to make Emacs as a whole better by suggesting the better parts of s.el that can be added to Emacs, or finding functions that could be renamed? - For most users, dash.el and s.el are very similar in nature. dash.el is already in ELPA. If we refuse s.el, isn't it inconsistent? What about the message we send? If these two libraries had only added, and not tried to redefine basic Emacs Lisp, I think the discussion would have been quite different. Encouraging people to use `s-titalize' instead of `capitalize' is a net loss for all Emacs Lisp programmers. There is I think a big difference between s.el -- which adds mainly trivial wrappers, and dash.el adds complicated control flow and functions for working on trees, etc. That is not to say that dash.el too doesn't fall into the trap of adding many trival wrappers.