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

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Thu, 9 Nov 2023 12:34:09 +0000
> Cc: acm@muc.de, dmitry@gutov.dev, bjorn.bidar@thaodan.de, emacs-devel@gnu.org
> 
> On Thu, Nov 9, 2023 at 11:38 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: João Távora <joaotavora@gmail.com>
> > > Date: Thu, 9 Nov 2023 11:06:02 +0000
> > > Cc: Dmitry Gutov <dmitry@gutov.dev>,
> > >  Björn Bidar <bjorn.bidar@thaodan.de>,
> > >  emacs-devel <emacs-devel@gnu.org>
> > >
> > > So I propose we let programmers use their judgement.
> >
> > That's fair enough, provided that those same programmers step up to
> > become the Emacs maintainers, and thus share the burden to at least
> > some extent.  Especially those of them who consider witty sarcasm a
> > useful style in a discussion like this one.
> 
> Did you read the rest of the paragraph from which you extracted that
> one line?

You should by now know me well enough to realize that I read
everything here.  However, I respond only to the parts where I have
something useful and non-trivial to say.

> Also, I would hope this is not a suggestion that I don't step to share the
> burden of maintaining things?  I do, certainly for all the features that I
> have I added to core in the past 10 years and frequently also to parts
> of the code those features interact with.  Do you often have to fix bugs in
> flymake.el, elec-pair.el, icomplete.el, eldoc.el, jsonrpc.el, etc...
> that I didn't care to take a look at in a reasonable time frame?  More
> importantly, to what extent are you and others significantly or often
> hindered by the style I use there?

I said nothing about your style.  Neither do I doubt that you know
your own code very well.  We all know our own code well.  I'm asking
you not to judge the burden of the maintainers in maintaining code
they didn't write nor even see, until you get to our place and do it
for a while.  Only then you will be able to realize the role of
obscure programming style and use of unfamiliar syntax in making the
job harder than it has to be.

> The problem of maintaining other people's code (which btw is 95%
> of all my professional experience) is not about programming techniques
> or even languages at all, it's about domain knowledge.

It is both.  In particular, when you need to understand why some code
fragment misbehaves, you need to understand the implementation and
what it intends to do, not only why.