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

[Philippe Vaucher]

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