Re: Installing cond* in core

[Dmitry Gutov]

On 28/01/2024 15:38, Alan Mackenzie wrote:
> Hello, Dmitry.
>
> On Sun, Jan 28, 2024 at 15:02:29 +0200, Dmitry Gutov wrote:
> > On 28/01/2024 14:38, Alan Mackenzie wrote:
> > > Pretending it didn't happen and failing to discuss it is not healthy for
> > > the project.  Routine bug fixes, and uncontroversial stuff is committed
> > > without discussion, yes.  Otherwise we'd be doing nothing else but silly
> > > discussions on emacs-devel.
>
> > The addition of pcase was a boon for the project.
>
> You're missing the point.  pcase has flaws, and even now, 14 years
> later, isn't satisfactorally documented.  All you seem to be saying is
> that pcase is better than no pcase.  I'd agree with that.
>
> But if pcase were so good, why is Richard writing a better replacement?

It all started with some people not understanding what pcase does and 
how it works. We're yet to see whether cond* is any better in those areas.

> > Its uses in particularly important areas, like bytecomp, might have been
> > a subject for discussion, but we don't really do that when all active
> > contributors to an area of code agree with the technical decision.
>
> You're being a bit vague there, but when have all active contributors to
> any area of code been in agreement?

A lot of times. Or in enough of an agreement for there being no problems 
to discuss.

> > And they did agree, otherwise the discussion would have had materialized
> > at the spot.
>
> That's not the way things happened.  pcase was simply installed in
> Emacs, with all its faults, and then proliferated round Emacs.  Where
> was the room for discussion?  Discussion is difficult after something
> has already been done.

We're doing it all the time by commenting on commits in an email to 
emacs-devel.

> If you're trying to say that pcase is better than nothing, so people use
> it, then I'd agree.  But if you're trying to insist it's as good as it
> could be,

One does not need to insist on that to disagree with your original 
statements.

> I'd ask you why Richard is spending a lot of time crafting a
> better replacement.

Rewriting other people's code that one doesn't understand has a long and 
varied history in software development. We even have a term for it.