From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel Subject: RE: The Guile junk drawer and a C plea Date: Sat, 20 Jul 2024 17:26:01 +0200 Message-ID: <20240720172548.prRm2C0062eE65L06rRme4@albert.telenet-ops.be> References: <20240629002027.13853-1-richard@freakingpenguin.com> <87h6co21qv.fsf@laura> <87r0bsxpoe.fsf@web.de> <4d9d9c2e-0830-4267-b8e5-1a50cb815508@msavoritias.me> <87a5ifyd0g.fsf@web.de> <20240719104617.pLmG2C00D4SnA1G01LmG1n@andre.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_A7934429-BEAF-450D-B542-691057629955_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30000"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Greg Troxel , "Dr. Arne Babenhauserheide" , MSavoritias , "guile-devel@gnu.org" To: Attila Lendvai Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Sat Jul 20 17:26:13 2024 Return-path: Envelope-to: guile-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 1sVByO-0007ah-ON for guile-devel@m.gmane-mx.org; Sat, 20 Jul 2024 17:26:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVBy8-0004Aw-UV; Sat, 20 Jul 2024 11:25:56 -0400 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 1sVBy7-0004Ah-4K for guile-devel@gnu.org; Sat, 20 Jul 2024 11:25:55 -0400 Original-Received: from albert.telenet-ops.be ([2a02:1800:110:4::f00:1a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sVBy4-00008u-Gv for guile-devel@gnu.org; Sat, 20 Jul 2024 11:25:54 -0400 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:69ee:5e58:e336:3248] ([IPv6:2a02:1811:8c0e:ef00:69ee:5e58:e336:3248]) by albert.telenet-ops.be with bizsmtp id prRm2C0062eE65L06rRme4; Sat, 20 Jul 2024 17:25:48 +0200 Importance: normal X-Priority: 3 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1721489148; bh=Mgokr2En+VleXG0c7P9S9vPbTNAzavvXsRayw/aS2Ec=; h=Message-ID:MIME-Version:To:Cc:From:Subject:Date:In-Reply-To: References:Content-Type:From; b=WDx/5apRslXgEMad8pkIKBXX0YYhvqk53jNWRPH1zXfLq1/FtMq5BQKiRId+hSJCJ iQvIjaEreJVlHn42m+mI2X9769k+z7hhDsNq/m3MuWTaRmY1WGOOvC6ArhLEdTwy4M +x4ulWHntYFALd0FIvYlNKwPliJoUNdwnYI7SWSzmVHaTYtlAjfh/pwQRDykwG43pE NUGLrBAQrQURBMi0BGMP6SxgRECnuYQb8F9r9HD0zQILMdI+9QJt57M77VUvx/TWs6 PUY9CZg6DUzvVTsykYGYAZzyvk+f8J5A1XKzjkBac/GgU4Ea7H6/wPDYx0dmtGTKZi v6Ni9FSHPzsZQ== Received-SPF: pass client-ip=2a02:1800:110:4::f00:1a; envelope-from=maximedevos@telenet.be; helo=albert.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22597 Archived-At: --_A7934429-BEAF-450D-B542-691057629955_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > >If there were more concern about compatibility -- all 2.0 programs will >=20 > >compile an work with 3.0 -- then we would not need to keep the old >=20 > >versions. >=20 > One of these changes is how #:autoload works. One of the options to prese= rve compatibility yet introduce the new behaviour, could have been to defin= e =E2=80=98define-module2=E2=80=99 (to be used instead of the (deprecated) = =E2=80=98define-module=E2=80=99) with the new semantics. Since their implem= entations would share almost all code, there wouldn=E2=80=99t be serious im= plementation costs(*). The only significant downside I see here is that =E2= =80=98define-module2=E2=80=99 is a rather uncool name, but that=E2=80=99s a= non-issue. >i'd argue with the statement that an aesthetic glitch is a non-issue. >the short version: see the Broken Window phenomenon, and the Turing Tarpit= . 'define-module2=E2=80=99 and =E2=80=98define-module=E2=80=99 aren=E2=80=99t= Turing tarpits: =E2=80=A2 Neither are Turing-complete (unless perhaps you do fancy stuff wi= th merge-generics and custom (GOOPS) method metaclasses, but then it was yo= ur own choice to turn it into a Turing-tarpit). =E2=80=A2 Both are (relatively speaking) easy to use. A slight difficulty f= or beginners is determining where in the file system to put the module (hen= ce the relatively qualifier), but both define-module and define-module2 hav= e the exact same problem, and AFAIK other programming languages aren=E2=80= =99t any better at this (hence =E2=80=98relatively=E2=80=99). =E2=80=98define-module2=E2=80=99 is not a broken window, it is a fixed wind= ow. Neither is =E2=80=98define-module=E2=80=99, it would be slightly outdat= ed in its precise semantics (and hence not recommended), but it does work d= ecently. The broken window here, is breaking the backwards incompatibility by _not_ = doing =E2=80=98define-module2=E2=80=99 or the like. (Doesn=E2=80=99t need t= o be =E2=80=98define-module2=E2=80=99 per se, other methods for preserving = compatibility exist as well.) =E2=80=98define-module2=E2=80=99 would be the= replacement glass (for the broken window) here. >the longer version: >you do not see how many potential contributors end up never touching the c= odebase because of stuff like `define-module2`. i know how i operate, and i= 've seen great coders exhibit similar behavior. i also participated in a fe= w discussions about how and why we got our impressions and made our decisio= ns. Neither do you (or me, for that matter) see how many potential contributors= never touch Guile, or stop touching Guile, or stay touching Guile but are = frustrated about Guile because of the _lack_ of stuff like =E2=80=98define-= module2=E2=80=99. That =E2=80=982=E2=80=99-suffix can be quite useful (for = compatibility). Also, almost by definition, those =E2=80=98great coders=E2=80=99 you are me= ntioning, aren=E2=80=99t actually great because of their lack of appreciati= on of backwards compatibility (*). Going by what I=E2=80=99m hearing about = these coders, I think I prefer _not_ having them touch the codebase. (*) In the past I=E2=80=99ve sometimes argued for _not_ preserving backward= s compatibility, but my opinion changed over time and this is not the same = situation. >there are various signs of disorder; a few major ones that quickly come to= mind: > > - a messy filesystem structure > > - badly chosen names for abstractions > > - a lot of work for M-x whitespace-cleanup > > - inconsystent code formatting > > - lack of code comments next to kludges. kludges are ok, but > uncommented kludges are a big red sign. > > - no attention for failing as early and as loudly as possible. > > - a lot of DWIM stuff, where e.g. some names are unnecessarily > generated, which makes navigating (grep'ping) the codebase > hopeless. IOW, unnecessary hindrance for code discoverability. None of these is the hypothetical =E2=80=98define-module2=E2=80=99. The onl= y thing that comes close is =E2=80=98badly chosen name for abstractions=E2= =80=99, but well, =E2=80=98define-module2=E2=80=99 would define a module, a= nd it is the second (*) incompatible version of this method to defining mod= ules. As such it seems a pretty decent choice of name (just a bit boring). (*) or maybe third, I=E2=80=99m assuming things here about Guile <2.2 that = I don=E2=80=99t actually know, the hypothetical =E2=80=98define-module2=E2= =80=99 / =E2=80=98define-module=E2=80=99 is just an example. > [...] > > and this is the reason i spoke up in this thread, not to argue for indisc= riminate > cleanups. retaining an ice-9 compatibility falls into the kludge category= , i.e. it's ok if > it's clearly marked as a kludge, and if it incurrs little extra maintenan= ce costs. Nowhere did I say anything about not properly deprecating =E2=80=98define-m= odule=E2=80=99. Best regards, Maxime Devos --_A7934429-BEAF-450D-B542-691057629955_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

> >If there were more concern about compatibility -- al= l 2.0 programs will

>

&g= t; >compile an work with 3.0 -- then we would not need to keep the old

>

> >versions.=

>

> One of these changes = is how #:autoload works. One of the options to preserve compatibility yet i= ntroduce the new behaviour, could have been to define =E2=80=98define-modul= e2=E2=80=99 (to be used instead of the (deprecated) =E2=80=98define-module= =E2=80=99) with the new semantics. Since their implementations would share = almost all code, there wouldn=E2=80=99t be serious implementation costs(*).= The only significant downside I see here is that =E2=80=98define-module2= =E2=80=99 is a rather uncool name, but that=E2=80=99s a non-issue.

 

>i'd argue with the statem= ent that an aesthetic glitch is a non-issue.

 

>the short version: see the Broken Window pheno= menon, and the Turing Tarpit.

 

'define-module2=E2=80=99 and =E2=80=98define-module=E2=80=99 aren= =E2=80=99t Turing tarpits:

 

  • Neither are Turing-complete (unless perh= aps you do fancy stuff with merge-generics and custom (GOOPS) method metacl= asses, but then it was your own choice to turn it into a Turing-tarpit).
  • Both are (relatively speakin= g) easy to use. A slight difficulty for beginners is determining where in t= he file system to put the module (hence the relatively qualifier), but both= define-module and define-module2 have the exact same problem, and AFAIK ot= her programming languages aren=E2=80=99t any better at this (hence =E2=80= =98relatively=E2=80=99).

 

=E2=80=98define-module2=E2=80=99 is not a broken window, it is a = fixed window. Neither is =E2=80=98define-module=E2=80=99, it would be sligh= tly outdated in its precise semantics (and hence not recommended), but it d= oes work decently.

 

Th= e broken window here, is breaking the backwards incompatibility by _not<= /i>_ doing =E2=80=98define-module2=E2=80=99 or the like. (Doesn=E2=80=99t n= eed to be =E2=80=98define-module2=E2=80=99 per se, other methods for preser= ving compatibility exist as well.) =E2=80=98define-module2=E2=80=99 would b= e the replacement glass (for the broken window) here.

=

 

>the longer version:<= /p>

 

>you do not see how many potential c= ontributors end up never touching the codebase because of stuff like `defin= e-module2`. i know how i operate, and i've seen great coders exhibit simila= r behavior. i also participated in a few discussions about how and why we g= ot our impressions and made our decisions.

 

Neither do you (or me, for that matter) see how many = potential contributors never touch Guile, or stop touching Guile, or stay t= ouching Guile but are frustrated about Guile because of the _lack_ o= f stuff like =E2=80=98define-module2=E2=80=99. That =E2=80=982=E2=80=99-suf= fix can be quite useful (for compatibility).

 

Also, almost by definition, those =E2=80=98great c= oders=E2=80=99 you are mentioning, aren=E2=80=99t actually great because of= their lack of appreciation of backwards compatibility (*). Going by what I= =E2=80=99m hearing about these coders, I think I prefer _not_ having= them touch the codebase.

 

(*) In the past I=E2=80=99ve sometimes argued for _not_ preserv= ing backwards compatibility, but my opinion changed over time and this is n= ot the same situation.

 

>there are various signs of disorder; a few major ones that quickly co= me to mind:

&g= t; 

> = - a messy filesystem structure

> 

> - badly chosen names for abstractions<= /p>

> 

=

> - a lot of work for M-x whites= pace-cleanup

&= gt; 

>= - inconsystent code formatting

<= span lang=3Den-BE>> 

> - lack of code comments next to kludges. kludges are ok= , but

>=C2= =A0 uncommented kludges are a big red sign.

> 

> - no attention for failing as early and a= s loudly as possible.

> 

> - a lot of DWIM stuff, where e.g. some names are unnecessarily

>=C2=A0 gene= rated, which makes navigating (grep'ping) the codebase

>=C2=A0=C2=A0 hopeless.=C2=A0 I= OW, unnecessary hindrance for code discoverability.

 

None of these is the hypothetical =E2=80=98= define-module2=E2=80=99. The only thing that comes close is =E2=80=98badly = chosen name for abstractions=E2=80=99, but well, =E2=80=98define-module2=E2= =80=99 would define a module, and it is the second (*) incompatible version= of this method to defining modules. As such it seems a pretty decent choic= e of name (just a bit boring).

 

(*) or maybe third, I=E2=80=99m assuming things here about Guile = <2.2 that I don=E2=80=99t actually know, the hypothetical =E2=80=98defin= e-module2=E2=80=99 / =E2=80=98define-module=E2=80=99 is just an example.

 

> [...]

> 

> and this is the reason i= spoke up in this thread, not to argue for indiscriminate=

> cleanups. retaining an ice= -9 compatibility falls into the kludge category, i.e. it's ok if=

> it's clearly marked= as a kludge, and if it incurrs little extra maintenance costs.<= /span>

 <= /p>

Nowhere did I say anything about= not properly deprecating =E2=80=98define-module=E2=80=99.

 

Best regards,

Maxime Devos

= --_A7934429-BEAF-450D-B542-691057629955_--