Re: What's missing in ELisp that makes people want to use cl-lib?

["João Távora" <joaotavora@gmail.com>]

On Fri, Nov 10, 2023 at 3:17 AM Po Lu <luangruo@yahoo.com> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > What the heck?  What I said, is that if Elisp _had_ better
> > ways of making compartments, such as namespaces, managing which
> > compartments are preferred in certain parts of code would be easier.
> > I stated multiple times that I tend to trust developers to pick
> > the tools they find most appropriate for the job.  I simply stated
> > that it's funny and ironic that the language whose influence you're
> > trying to exorcize is precisely the one with one of the best
> > tools to do that exorcizing.
>
> Which is tantamount to, or at least comes off as, arguing in favor of
> that language's influence.

No, not mounting any tantas, I was just making a joke.  But yes, of course
I like Common Lisp.  I like C++ too (not as much, tho) and it pisses off
C people, too.

> Granted, the foregoing is something of an overstatement.  But the
> alacrity with which programmers seize at opportunities to employ cl-lib
> does call for one.

But that leitmotif is everywhere (and us much less strong in open-source,
btw).  Surely if you've ever worked at a large enough company you'll see
bizarre code from people not working there anymore.  And that goes for
everything.  You think everyone will forever be grateful to read your
300-line inline-all-the-things functions in touch-screen.el when you're
not around to explain what they do?  They won't.  It makes no sense
to single out any given library for this evil, especially not cl-lib.el
which is a well-understood stable piece of kit.  In Emacs core and
just as strongly outside it.

> > There are no "beliefs" in Common Lisp's, neither should there be
> > in Elisp.  I don't think it helps your case to repeatedly evoke
> > religion.
>
> Really?  Here is one example to the contrary: keyword arguments.  No
> Emacs Lisp built-in takes them, yet it is scarcely possible to name a
> Common Lisp list manipulation function that does not.

Many examples of Emacs Lisp functions take them.  Even Richard seems
to have come around to their usefulness.  CL functions take them in
consistent ways, but you can use them without keyword arguments if
you're stubborn enough.  Anyway, it's not a "belief", it's just a
good way to provide versatility for functions.

> > Every other choice also has "implications".  Most people favourable
> > to cl-lib in this discussion know why they chose to use its functions.
> > I wouldn't be so condescending.
>
> Yet few of these people consider the impact their decision makes to
> others, who will in due course have the responsibility for reading this
> code pawned off them.

Why do you exempt yourself from this irresponsibility?  Can't you see
this is all subjective and it seems a bit arrogant to say "my code is
so responsible"??  All code is bad.

> > Hmmm, a bit vague, no?  Humor me: if it's really so easy and so
> > readable please write out your preferred equivalent of, say
> >
> >    (cl-set-difference l1 l2) ; hopefully obvious, like l1 - l2 in python
>
> (let ((list nil))
>   (dolist (x l1)
>     (unless (member x l2)
>       (push x list)))
>   (dolist (x l2)
>     (unless (member x l1)
>       (push x list)))
>   list)

>
> (catch 'tag
>   (let ((index 0))
>     (dolist (tem someseq)
>       (when (eq (car tem) probe)
>         (throw 'tag index))
>       (setq index (1+ index)))))

Nuff said :-)  .  So if multiple set difference operations or multiple
index-finding operations are needed you write these choo-choo trains
again and again.  That sure explains the 300 lines.

> > Some get confused by cl-labels, some by archaic things like rplaca,
> > some by new stuff like static-if.  Doesn't matter what is alias to
> > what, when you see both these things  in code you don't know what
> > they do until you look them up.  And many times you'll think "there's
> > a much better way".
>
> There's not much of a point in arguing against such patent absurdities
> as considering the operation of setcar as complex as that of cl-labels,
> is there?

I guess not for human versions of --finline-functions who think,
or rather "believe" that such common practices for code reuse
as subroutine encapsulation is "balkanization".  It's probably "patently absurd"
for them yes.

João Távora