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

[Alan Mackenzie <acm@muc.de>]

Hello, João.

On Thu, Nov 09, 2023 at 11:06:02 +0000, João Távora wrote:
> On Thu, Nov 9, 2023 at 10:05 AM Alan Mackenzie <acm@muc.de> wrote:

> > >    If it needed any confirmation, I too like cl-lib and I too help
> > >    maintain other people's code in the Emacs core tree as well as
> > >    maintaining a number of libraries I have authored.
> >
> > There's a difference between liking cl-lib and advocating its
> > indiscriminate use.  I don't think you've done the latter in this (and
> > related) threads.

> Yes, you're right.  Indeed I don't' advocate for its indiscriminate use,
> just as I don't advocate for indiscriminate use of anything, except
> perhaps drinking water and brushing teeth.

> > Nobody who likes cl-lib has yet addressed the point made by Richard and
> > (less eloquently) by me, namely that the incorporation and use of cl-lib
> > swells the size and complexity of Emacs Lisp to the point of making
> > maintenance difficult.  What is your view on this important point?

> That it doesn't make maintenance any more difficult than any other
> Elisp construct, be it very old and curiously named like 'rplacd' or
> much, much newer like `seq-do` or `pcase-lambda`.

OK, thanks for answering the question.  Please bare in mind that other
people's experience of maintaining code using cl-* is very different.

> My specific view on cl-lib.el is that it brings us a small part of
> the results of  non-trivial design work put in when important figures
> in the Lisp world met  regularly for many years to deliver what has
> proved to become excellent,  battle-tested, widely understood and
> impeccably documented programming abstractions.

> What I'm reading so far in this long discussion is that the argument
> of its detractors isn't really that cl-lib isn't good, but that
> it is superfluous and that learning it is a burden on maintainers.
> Well, it's just as superfluous as all of Elisp apart from two handfuls
> of primitives, I guess.

No, it's completely superfluous, even if it can be convenient.  Learning
it is a burden because its objects and abstractions are, well, very
abstract as well as being badly documented.  They have little
relationship to anything concrete in Emacs, and they are typically
complicated with many seemingly random details in a way that Emacs
primitives are not.

> Or any programming language for that matter, if you know enough
> machine code.  Or any other programming abstraction I happen not to be
> familiar with.

I am familiar with machine code.  It is perhaps pertinent to remark that
modern processors tend to the reduced instruction set model - that the
complicated "do it in one single complicated instruction" notion doesn't
help the writing of good compilers, or the running of programs
efficiently.  I suspect that analagous logic applies to programming
languages too.

[ .... ]

> João

-- 
Alan Mackenzie (Nuremberg, Germany).