From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Sat, 9 May 2020 14:05:28 +0200 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> <87wo5mc04t.fsf@fastmail.fm> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="35199"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Joost Kremers , Richard Stallman , Emacs developers To: "Alfred M. Szmidt" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 14:06:35 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 1jXOFW-00091T-Pc for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 14:06:34 +0200 Original-Received: from localhost ([::1]:34642 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXOFV-0002tU-Bu for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 08:06:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32990) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXOF0-0002UL-3Z for emacs-devel@gnu.org; Sat, 09 May 2020 08:06:02 -0400 Original-Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:37718) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXOEw-0003OB-AR; Sat, 09 May 2020 08:06:01 -0400 Original-Received: by mail-lj1-x232.google.com with SMTP id o14so3402579ljp.4; Sat, 09 May 2020 05:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rEtVprL3CaJR8YbqQ44THdhDMHCIevEjAp5JJXLoXgQ=; b=rlRJU930k/k2k+dDjW5dXMXLCuu3ddiTCrCZ8rWlz1IUuLPSyqGhms07lkOvZ7Fq8R 1wZXsPo9gn1f9G0u6dn8KSGo6XuLmmwU4eUJane6XO1ShvAxfmdKMXlMdxqOVSOeQeZt zBii52GzyEA53mHQKBTydo6iHBz6jEKUhjPI/LbxclUNsiTmKk8Vh/9YoiPulseA9hnh IV3h+ndtkrHv9JJ9rsyWaqeL4dCA5yEw3kSLwN7dqGdij5LeIx6GJcmnmN1He3SEuOvO ZZbB5TyxuQcNDA1pjNA9ZjSLefgQyLWMkstoTDF7CgYhHCKX25XDjQmtx5laYjW3g8MS QVQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rEtVprL3CaJR8YbqQ44THdhDMHCIevEjAp5JJXLoXgQ=; b=E7kBpIxIKZ2Yw98Z5RJyekhif/x4ot+NvZkHaQp49HFfYy88QOhLaMBdDxaF6szozc /9ZUR4M13b8vIH3uv/Lbcre3vOz3LPWVD5z0b/oFEh8ACLkJDS50Jud5Ay2O5s1pONzN crsFoGUFXc4omgug2Ms1k35rbSJYam1P2PhYX+gvtknbXBh7dZ/fWVjTozAauc/V/EYU Wew+HAxoau60SOwNdZaMlerS3i/fhRovh8bfOWyqlBZEbOZOh6nBarKq8Q9zw8U7tRQH unDeMxVZjbnnRcL1/ST57dljQsdjkXZcx5CboPgFadcM2fNtjPXgkSNZ3KT+3cJG1/ka Ta7Q== X-Gm-Message-State: AOAM533dBm85Sjq7ys8Pzs0Gx942YNUH6KOLyn0SINY/oDPP9GXd8xTv kDWGMJ9NjGZr+3g5IVX+DFe+hxm9I9BkuWcf4FLZOgW29zs= X-Google-Smtp-Source: ABdhPJx8FEucO7fJohE5cgjtos8xuFCrX4htssBPJPEEIJkGoPBzNgQGDSb0qFXhZ10sQnDXkNH7qNVue8kZh2YCiRk= X-Received: by 2002:a05:651c:2011:: with SMTP id s17mr4344556ljo.242.1589025955011; Sat, 09 May 2020 05:05:55 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::232; envelope-from=philippe.vaucher@gmail.com; helo=mail-lj1-x232.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:249408 Archived-At: > 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. I don't understand... is your point that dash.el/s.el would not be useful to you? Yeah sure, not all packages are useful for everyone. Or is it that you still don't know what dash function "maps" to what elisp function? > 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. I'm not talking about reading the code, just the API. The API is straightforward for a lot of users. Maybe that's the point you are trying to make, that it is not straight forward to you. I think it boils down to this: https://en.wikipedia.org/wiki/Higher-order_programming Some of us are exposed to a great deal of languages, and in most of these we can do high order programming Quoting the wikipedia article: Prominent examples of languages supporting this are Wolfram Language, C#, Java, ECMAScript (ActionScript, JavaScript, JScript), F#, Haskell, Lisp (Common Lisp, Scheme, Clojure, others), Lua, Oz, Perl, PHP, Prolog,[1] Python, Ruby, Smalltalk, Scala, ML, and Erlang. I'd argue that even C++ supports it http://www.cplusplus.com/reference/algorithm/ Thus I think we found why both camps find their perspective "obvious" and has trouble understanding the other side. > 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. Well it'd be `s-capitalize` instead of `capitalize` but I think I understand your point, you think in terms of what the name is now how changing it is a burden. I think we disagree about what constitutes going forward but that's ok. > 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. Yes, I'm glad we have at least that. There will be proposals in that direction in the future. > 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? Well there isn't any forceful insistance of adding s.el to Emacs core as far as I know. There is an incomprehension about why not add it to ELPA, but it's more for ELPA's sake than mine. I use MELPA so I don't really care. > - 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. Again not the best example but ok. Please remember that what you see as a net loss is a net gain for most people used to high order programming discoverability.