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

[Göktuğ Kayaalp]

On 2020-05-19 06:34 +03, Stefan Monnier wrote:
>> I don’t think it’s that much of additional complexity given many
>> popular programming languages have multiple ways to define one off
>> closures: Python (inline def vs. lambda), JavaScript, Ruby, even C++
>> these days AFAIU.
>
> How many non-Python programmers have to touch such Python code?
> [ Repeat that same question for your other examples.  ]

That’s fair.

> Anonymous functions are part of the subset of Elisp that random Emacs
> users are exposed to in normal .emacs settings.  Any change that makes
> this subset more complex is significantly more harmful than changes to
> other parts of Elisp, so it needs to come with bigger upsides to pay
> for itself.

One problem with this argument is that random, non-programming users are
only exposed to those things in their .emacs files which they put in
there in the first place.  So if there is some syntax X in there, they
either put it in there willingly, i.e. they knew what it does (to an
extent, at least), or they copied it from somewhere where the context
and contextual help would make it fairly easy to understand what it is
going on.

IMHO, we shouldn’t be that protective of non-programming users.  After
all, almost all concepts they’ll have to work with will be novel to
them, so I doubt a few shorthands would make that big of a difference.
I’d even say Elisp is a nicer environment to learn about the more
advanced concepts of programming because the unusual opportunities of
online inspection, introspection, and documentation Emacs provides.
Things like control structures or OOP are black boxes in even Ruby or
Python, and if you needed/wanted to look under the hood, you’d need to
fetch the source code (a non-trivial task) and study it to find what’s
where, whereas in Emacs if you want to see how ‘if’ is implemented all
you do is C-h f if RET & hit a link, and you have the C code before your
eyes.

        -gk.