From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Installing cond* in core Date: Sun, 28 Jan 2024 14:32:48 +0000 Message-ID: References: <868r4a6lbb.fsf@gnu.org> <3cf3ba2d-873f-44d8-81f4-420d8954fd8e@gutov.dev> <6415235c-b06c-41b2-9909-39ecc74a6873@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25361"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , stefankangas@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 28 15:33:41 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rU6E9-0006Mn-0p for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jan 2024 15:33:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rU6DP-0006U9-Ax; Sun, 28 Jan 2024 09:32:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rU6DN-0006Tg-QO for emacs-devel@gnu.org; Sun, 28 Jan 2024 09:32:53 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rU6DL-0006zy-MU for emacs-devel@gnu.org; Sun, 28 Jan 2024 09:32:53 -0500 Original-Received: (qmail 89027 invoked by uid 3782); 28 Jan 2024 15:32:49 +0100 Original-Received: from acm.muc.de (pd953ae19.dip0.t-ipconnect.de [217.83.174.25]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 28 Jan 2024 15:32:48 +0100 Original-Received: (qmail 10018 invoked by uid 1000); 28 Jan 2024 14:32:48 -0000 Content-Disposition: inline In-Reply-To: <6415235c-b06c-41b2-9909-39ecc74a6873@gutov.dev> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:315554 Archived-At: Hello, Dmitry. On Sun, Jan 28, 2024 at 15:48:04 +0200, Dmitry Gutov wrote: > On 28/01/2024 15:38, Alan Mackenzie wrote: > > 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. I don't think that's true. People understand how it works. Enough people have difficulty reading and debugging pcase and its numerous variants to matter. > We're yet to see whether cond* is any better in those areas. This is true, but it's highly likely cond* will be better. It's being designed by an expert designer, and has been through a phase of open comment and revision. Also, it takes advantage of the experience of pcase. [ .... ] > > 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. To have been effective, such comment would have resulted in the removal or fundamental alteration of pcase long after it had been ground into the core of Emacs. That just wasn't going to happen. You weren't there at the time. I was. I was completely unaware of pcase happening, and it was a shock being confronted by it for the first time. > > 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. You cannot disagree with my original statement made last night. As I said, you weren't there at the time. > > 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. You're suggesting in that paragraph that the fault lies in Richard's lack of ability. That's uncalled for. He has trouble reading and understanding code written with pcase, as do I, and as do others here. The fault is in pcase; it is flawed. At the same time, it is not doubted that there are people here fully conversant with pcase. Having such a split in the project is a bad thing. -- Alan Mackenzie (Nuremberg, Germany).