Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]

[Alfred M. Szmidt]

   >    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.

I cannot address both s.el and dash.el at the same time, they are two
extremely different libraries that have nothing incommon.  Lets please
stop mixing them up as if they are the same.

s.el has little point, it is thin wrappers around Emacs Lisp
functions, and it has been explained why it isn't suitable (as is).

dash.el is more interesting, but since that is not how you generally
write Lisp (in general), it is hard for me to find something I'd use
it for.  And so far, nobody is willing to provide concrete examples on
that topic and instead telling everyone to just go and read the code,
I did -- still no clue what or how to use these functions in the
context of Emacs Lisp.

Can you give some examples of using dash.el?

   > 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. 

That is a very naive view of the matter.

Lisp is one of the oldest high level programming languages that allow
for higher order functions, s.el has nothing to do with that.  

dash.el adds interesting constructs that are available in other
langugaes, and some might be interesting to add in Emacs Lisp.

   >    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.

Adding s.el to ELPA isn't about changing any names, they are two
different topics.  Renaming existing functions in Emacs is, and should
be, a long process that shouldn't be done lightly.

s-capitalize is something different, and unrelated to the Emacs Lisp
function `capitalize'.  s-capitalize does a downcase on all words
except the first one, that is not the behaviour of `capitalize'.  The
corresponding function from s.el is s-titleize, which is a simple
alias for `capitalize'.

I picked this particular function because it is confusing to existing
Emacs Lisp users, since its behaviour is entierly different.

   > 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. 

That is not true, it is exactly the opposite.  See,

  https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg00850.html

Adding something to Emacs (be it Emacs or ELPA) has a bar, we
shouldn't blindly add anything and everything.

   >    - 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.

This again mixes a different matters, one of higher order functions
and one of discoverability.  Neither s.el or dash.el make Emacs lisp
more discoverable.

Adding a well design higher order function library is I'm sure
something that would be welcome in Emacs.  

dash.el has some interesting functions for that, but could use better
function names for them, and removing the trivial aliases would be a
good start to maybe add them too Emacs (either via ELPA, or in Emacs
proper).

The objection here isn't what these libraries provide, but _how_ they
provide it.  As I mentioned before -- if these libraries would
concentrate on extending, not replacing, Emacs Lisp it would be a
different topic.    

Even the simple suggestion by RMS to call the library for clojure-lib
or similar for functions that follow the semantics from Clojure would
be vastly better.  That makes it very clear that these are not
functions that follow the Emacs Lisp style.