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

[Lars Ingebrigtsen]

Stefan Monnier <address@hidden> writes:

> Don't get me wrong: if I were to design Elisp from scratch, I'd most
> probably choose a syntax for functions which has a handy "no explicit
> parameter names" shorthand like `#(f % 1)` and also naturally
> generalizes to the "fully explicit parameter names".

Writing Clojure, I do find this stuff handy.  Reading Clojure, on the
other hand, I don't.  :-/

When I mentioned that (reduce + #(* %1 %2) things) was valid Clojure on
an IRC channel, people thought I was just joking.  When a programming
idiom is indistinguishable from satire, I think that may perhaps mean
that it's not a particularly good idiom.  On the other hand, Clojure is
really popular, so what do I know?

I have great sympathy for the idea that Emacs should cater to multiple
styles of programming.  I mean, it's Emacs: You should do whatever you
want.  If people like dash.el, then of course they should be allowed to
use that to their hearts content.  And people are voting with their feet
(I mean fingers): People really like s.el and dash.el.

On the other hand, Emacs has been around for 40 years, and will be
around for 40 more, and programming idioms come and go.  If Emacs had
succumbed to the "let's add more Perl idioms!" in the late 80s and
"let's make everything more Java-like!" in the 90s, then we'd be staring
at a much less cohesive code base.

Take things like Clojore-like threading: It's a sop to people who come
from Java and jQuery.  They can't read "inwards out", so:

(defn calculate []
   (reduce + (map #(* % %) (filter odd? (range 10)))))

becomes

(defn calculate* []
   (->> (range 10)
        (filter odd?)
        (map #(* % %))
        (reduce +)))

But while this syntax makes sense in jQuery, it's ambiguous where the
parameters are supposed to go in Lisp, so you have -> and ->> for two
common cases, and you have to write your functions with that in mind,
and then you have others where this doesn't work and you rewrite and
and and.

Some idioms translate well between languages, and some don't, but leave
a brittle, awkward, frustrating language surface, and I think that
that's where Clojure ended up.  If you read programming blogs, you'll
see an enormous enthusiasm for Clojure a few years back, and then less
and less, and there's a whole bunch of projects written in Clojure that
have been ported (back) to Java, because there just wasn't much of a
value proposition there anyway.  It's simply not a good Lisp.

(That's my impression from years of reading HackerNews (yeah, I know),
anyway.)

dash.el and s.el allows the masses of people coming from Clojure(script)
and JavaScript to acclimatise to Emacs Lisp a lot faster.  That's good.
But I'd rather not have to read the resulting un-Lispy code for the next
few decades in Emacs itself.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no