[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]
From: |
Phillip Lord |
Subject: |
Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] |
Date: |
Fri, 08 May 2020 23:23:02 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (gnu/linux) |
address@hidden (Alfred M. Szmidt) writes:
> Finally, dash just adds a lot of things ready rolled. If the history of
> programming languages tells us anything at all, it is that languages
> tend toward higher and higher levels. Emacs could do with more of this.
>
> I think Emacs already does that; only that the POV is just different.
>
> The way we manipulate buffers doesn't lend it self easily to a
> `functional' paradigm -- consider only forward-char!
>
> I find both forms easy enough, they are easy to understand and easy to
> write. I barley need to understand what each of those functions do to
> understand what the code does. I don't see how dash.el or s.el could
> make the above easier to grok (one reads code more than writes it).
>
> What do you suggest as the alternative?
Using my own library (m-buffer) this switches all "a" with "x".
(defun switch-a-1 ()
(interactive)
(m-buffer-replace-match
(m-buffer-match (current-buffer) "a")
"x"))
or just the first two occurences
(defun switch-a-2 ()
(interactive)
(m-buffer-replace-match
(-take 2
(m-buffer-match (current-buffer) "a"))
"x"))
or if you don't like too much indentation
(defun switch-a-3 ()
(interactive)
(--> (m-buffer-match (current-buffer) "a")
(-take 2 it)
(m-buffer-replace-match it "x")))
>
> > > or what to use it for.
> >
> > Well, you use it if you want to program in a Clojure-like style.
> >
> > Isn't that the crux then?
> >
> > I as a user want to program in an Emacs Lisp style, not Clojure-style.
>
> Emacs lisp is not a constant, of course. One of the joys of lisp having
> very little syntax it is possible to re-invent for different
> generations. Many people do find
>
> End of sentence missing?
"Many people find that they want to program in different styles", or
something like that!
> I disagree that Lisp lacks syntax (it has probobly more of it than
> other languages)
Lisp has parens and some other stuff. It's hard to add control-flow
structures in most other languages, while it's trivial in lisp.
> or that one should `re-invent' things. But that is more of a
> philosophical debate than anything.
And the soul of what we are talking about I think.
> > As a user, I found many of the functions to have alien names, strange
> > behaviour and very unintuitve to use in the style that is Emacs lisp
> > (Classical Lisp?). But some functions seem useful, though with
> > non-Emacsy names and calling conventions.
>
> Yes, this is true. seq.el does a better job there. But, again, it
> assumes we cannot re-invent Emacs. The question is whether we
> should. 2million downloads for dash.el tells me many users think the
> answer is yes.
>
> I don't know what it means to re-invent Emacs, or what it would entail
> so that is making a leap of faith into an abyss of unknowns.
>
> What I do know is that "millions of downloads" is not good metric of
> what is good, e.g. many more people download non-free software than
> free software.
It's not a bad metric either! Yes, there are many people downloading
> We do not know, or so I assume, how many of those supposed millions
> activley use dash.el, or if it is simply a dependency that is
> automatically pulled in by some other package.
Well, it's a programmatic library, so "actively using" is really about
being a dependency. So, I downloaded MELPA till I got to packages
starting with "i" and grepped for "require 'dash", which gets me 160
matches. It's a lot.
> And even so, it doesn't automatically mean that it would be a good
> addition to Emacs -- such things shouldn't be decided only based on
> popularity.
Happy to hear the criteria that you would apply.
Phil
- Re: ELPA policy (was: Imports / inclusion of s.el into Emacs), (continued)
- Re: ELPA policy (was: Imports / inclusion of s.el into Emacs), Richard Stallman, 2020/05/09
- Re: Imports / inclusion of s.el into Emacs, Alfred M. Szmidt, 2020/05/08
- dash.el [was: Re: Imports / inclusion of s.el into Emacs], Joost Kremers, 2020/05/08
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Alfred M. Szmidt, 2020/05/08
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Phillip Lord, 2020/05/08
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Alfred M. Szmidt, 2020/05/08
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs],
Phillip Lord <=
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Stefan Kangas, 2020/05/08
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Alfred M. Szmidt, 2020/05/09
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Phillip Lord, 2020/05/10
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Richard Stallman, 2020/05/08
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], 조성빈, 2020/05/09
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Alfred M. Szmidt, 2020/05/09
- Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs], Eli Zaretskii, 2020/05/09
- octal escapes with rmail [was: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs]], Alfred M. Szmidt, 2020/05/09
- Re: octal escapes with rmail, Eli Zaretskii, 2020/05/09
- Re: octal escapes with rmail, Alfred M. Szmidt, 2020/05/09