From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Dr. Arne Babenhauserheide" Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] The Guile junk drawer and a C plea Date: Sat, 20 Jul 2024 15:01:42 +0200 Message-ID: <87wmlgkyix.fsf@web.de> 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/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9500"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Maxime Devos , Greg Troxel , 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 15:02:26 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 1sV9jF-0002IT-VB for guile-devel@m.gmane-mx.org; Sat, 20 Jul 2024 15:02:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sV9iz-0001yl-8K; Sat, 20 Jul 2024 09:02:09 -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 1sV9it-0001yT-P8 for guile-devel@gnu.org; Sat, 20 Jul 2024 09:02:05 -0400 Original-Received: from mout.web.de ([212.227.17.12]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sV9iq-0006Hj-Qb for guile-devel@gnu.org; Sat, 20 Jul 2024 09:02:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=web.de; s=s29768273; t=1721480504; x=1722085304; i=arne_bab@web.de; bh=kftEU57Kxy+XStPp9gRd2WVmxOxdHzHTYt4NUtcy7Qk=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=kCfswDIf7j/JYAyGtoCWOGFbixqhXnPDrLd21Uy0Q4WtPS+vNt/P4jnWtcSS8QUT Lv2OVdVzzXoBPZBGgcShVjzgC2P7FzwjQN/TK5Ej5Eui1T522QULBinrwJknUaeuR TFhWX1VSmdCmpFNXehIqHH7+ciXbT15eX2LpN4CSJmfl1Q73tlnPHR7n0rcX64FlA g/7kTsVwh9dobcsuFSEZsKoitmSuH5MhBHB+CUT3XGGtZJbUbC7Ue3vRk/bALhSDC DJhjyiH0JlPpY6VeClyzPllOAJim6M1gQ5xtD8ZQ6cq9K3Z+b0Er+uYik0GeYRCxd WouPR5EayNIVCLOuKg== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from fluss ([84.165.21.10]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MA4fI-1sbBJq3CbS-00A1b9; Sat, 20 Jul 2024 15:01:44 +0200 In-Reply-To: (Attila Lendvai's message of "Sat, 20 Jul 2024 09:34:22 +0000") X-Provags-ID: V03:K1:Zw+p3iRR7K1bKbzmEa9+tybILIDw6DTZSaqMpDh3dNKXy89fDH8 3KRwTfl2jM3FU/IAU9IfmsvTSC6dyrSW/kEkX7CztqPcgy+CTTY+hUPROetgIwTt/z/rYJ/ yH0OsGSj0LTvjvh23Ac4CQ/U964df51yP1W0CYE+FcXjEfN8sHULrxI01fJbZLtoXUbqvxG 1RVFSqog1VpmQtqhNBthg== UI-OutboundReport: notjunk:1;M01:P0:445QJkNndgU=;K42dGA5IDslFkH7/cXyKFZsjDW3 JDPqz2RtBPEBGLQeTyFlZTQLZJGIT9x1oR/6Rcqvfs8/jBdMKcq1XdRjXS20g+AG7unJv63ul xtakplsEe8f8XRa8aBsFVQ4DAP0EkIzLQHVJca7VfnfcxKrA2eWBXuVt/JCrjQD0Ar/yM2GgT QhqinwBdS2N/sMRXdsF3u6oyTnA6Uugwu7J6AzasAgn7ZxxImMiCu31DZ0p9fyw/g0diMQ8zV 39B3Ks309pXG5lRbgr7QO/02yFdlDgbL+ZlCgpAxBqzeLKEhpif6eWehHoqVPicdJES7as31K mD9YTGF7FzqSWgwQ38is8qgsL6y0YNJ5YrUAM/SLIYFiE7LfXYYETfG33kz4qt7zNxTCeV7at 8PwGhihThmN6r2chSo3DA+hDt+5GJllsKaP8d2MrQ+s/sGZPYpI+E9tBzExWl4UiQzZHG9FQR J4PvCSLPdqHv+vKOLNkduR3/acI11+S7n59RUoHFcUNY16AUiW3jYD3ksnhVJwsoSKo6OdA55 RUQzWINMvjepQa9VI/No5H68c21dWBjlp4h57zH2uxiPmsrEzDIz1Y8SGjQWXV2EMUWdcn441 dRIuopti4JD0ND0fYVDGFHj/+kGUjsqROK7HIsnfxLV5+XiS376YJj8qAoIa70xOLycruDRhR uT07Lj1sVAJ4mXsW88Uai/fRQq0ZsXzQyByjcQQ1pjv5hbG9L1yvApXKm8iR6TsqCdipcisnP 9dWXuGy9dVNC8/DHNEZrEHkfD2/iolFbuzaNRVOGdVdVZ+M2caEaoWIaf2Slri2z8xX3MoQs Received-SPF: pass client-ip=212.227.17.12; envelope-from=arne_bab@web.de; helo=mout.web.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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:22590 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Attila Lendvai writes: >> >If there were more concern about compatibility -- all 2.0 programs will >> >compile an work with 3.0 -- then we would not need to keep the old >> >versions. >>=20 >> One of these changes is how #:autoload works. One of the options to >> preserve compatibility yet introduce the new behaviour, could have >> been to define =E2=80=98define-module2=E2=80=99 (to be used instead of t= he >> (deprecated) =E2=80=98define-module=E2=80=99) with the new semantics. Si= nce 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, b= ut 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 Tarpi= t. Do you know that the Broken Window theory has been debunked? https://cssh.northeastern.edu/sccj/2019/05/21/researchers-debunk-broken-win= dows-theory-after-35-years/ To expand on that: none of the problems you name are connected to using a not that beautiful name where it is *required* for backwards compatibility. Taking care of backwards compatibility is *to me* a sign that a project takes the code and its users seriously, and all the signs you list are not connected with accepting some annoyances where they are required to keep tools working but rather with happily breaking tools that build upon it. With choosing the easy path that=E2=80=99s right when seen *in iso= lation* instead of the more complex one that=E2=80=99s right in the larger context = of people using the project. If such breakage happens often, the project may have clean code, but its beauty is shallow because it rejects the deeper understanding of how others use the code and are affected by changes. In contrast, thinking before adding an abstraction and tidying up annoying parts without causing breakage yields a system that gives confidence that the project will have my back for years to come. Aside: the threads here made me realize something about Python and how it=E2=80=99s used in AI stuff that I didn=E2=80=99t understand before. Befo= re Python 3, Mercurial was kind of the poster-child of Python best practices: Build as much as possible directly in Python and only go down to C where it is absolutely required to fulfill workflow requirements. Profile before optimizing. Python 3 broke Mercurial horribly. The new AI tools that form the main users of Python today are different. They just use Python as a thin veneer for a huge C++ core. This insulates them from breakages in Python, because the amount of complex Python code they have is pretty small.=C2=B9 By breaking many of the tools that took a deep dive on Python to actually follow the advertised best practices, these best practices changed. =C2=B9 I checked whether I=E2=80=99m wrong after writing this =E2=80=94 bec= ause I might have been: I=E2=80=99m far from all-knowing, and I mostly see Python from the sidelines these days: I stopped being an enthusiastic Pythonista around 2013. But here=E2=80=99s a representative article about uses of Py= thon: https://www.coursera.org/articles/what-is-python-used-for-a-beginners-gui= de-to-using-python - Data analysis/ML (thin veneer) - web development (framework=C2=B2) - automation/scripting (thin veneer for IO and subprocesses) - testing/prototyping (thin veneer for compiler/bad idea=C2=B3) - everyday tasks (thin veneer) =C2=B2 with the frameworks you limit your own code and can hope that the framework will shield you from most language breakage. Even if it isn=E2=80=99t stable either, limiting your own code keeps maintenance cost low. =C2=B3 because the prototype may go into production and then it will be hit by the same problems that hit Mercurial. > there are various signs of disorder; a few major ones that quickly come t= o 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. > 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. With the pretty harsh words I wrote above, I think it=E2=80=99s important t= o say this here again: We agree on that. And I also think that marking kludges is important. And that if we were to take that decision again, it would be good to look for a better name than define-module2 (it=E2=80=99s too late for that,= but maybe keep this as a lesson for the future). But I see an even worse problem which would be even easier to fix: Lassi Kortela writes: > BTW, > https://www.gnu.org/software/guile/manual/html_node/Concept-Index.html > only has one mention of ice-9. That would be a much easier explanation why ice-9 can cause problems to newcomers. They are not told about it where they actually look. It would be easy to state in more places "the standard library of guile is called ice-9 (see [history])". It would cause no breakage at all and fix the problem that newcomers don=E2=80=99t know where to look. I would suggest this as a start: diff --git a/doc/ref/tour.texi b/doc/ref/tour.texi index c0ecb1699..7142394a5 100644 =2D-- a/doc/ref/tour.texi +++ b/doc/ref/tour.texi @@ -210,6 +210,15 @@ processing or command line parsing. Additionally, the= re exist many Guile modules written by other Guile hackers, but which have to be installed manually. =20 +Most provided modules use one of three different prefixes: + +@itemize @bullet +@item @code{ice-9} includes guile-specific modules: the standard library o= f Guile. @xref{Status, History of ice-9, History of ice-9} +@item @code{scheme} includes modules from the RnRS standard: @url{https://= standards.scheme.org/}. +@item @code{srfi} includes Scheme Requests For Implementation; SRFI=E2=80= =99s: @url{https://srfi.schemers.org/}. +@end itemize + + Here is a sample interactive session that shows how to use the @code{(ice-9 popen)} module which provides the means for communicating with other processes over pipes together with the @code{(ice-9 Also we could do cleanups like merging the gc-benchmarks folder into the benchmark-suite folder. Best wishes, Arne =2D-=20 Unpolitisch sein hei=C3=9Ft politisch sein, ohne es zu merken. draketo.de --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAmabtTcQHGFybmVfYmFi QHdlYi5kZQAKCRAT741FJAPD61mxEADCcZCH3+4vn4Q3emlxnZXATsMEJFrnfJRL PH6QClM56sPjBj1fso9zHanWjM9Jno+AD0PL9ZCZmueN07dU4y9mm5aZmwyKP8kK Uhld3vvzo4iGFtRs+Bt/KfOdGC4CjxGcFGwKAdMGrFa8CSzB5TrUC4hiyL1cpU9u XNxxckUS2esCjXot5DTIciVKoanfuekFA/M/zUzcDMTrj4UaWYjXaBnAQAEzvCB0 nYFr1ZdD0nKpofRUHeI8E0xqrOsM6N0e9g0th6uKoXpBTuF1eLWl3Msxp4VHbQwY WBL30ygVKyCM+myv9+Amn+Wai8Voskx1F8QTdcO2nyHtWew8MNpk8VZ2S+Xqcfqu m0E/61Xa2SW0vgE7Pfi1JLgQteZVFHxmrP+5qAqYN7tMdHcr/knj5afE+VtC5NLA ng3xutkt/ivLxkBLsWi9FCg9FdxNZQeCzvQup0dk7SHmTAGZ33KLIoLuujENPMQq LyQOPKao61wGa3AeSRpObZuRIdm0B2TGfzDpUHyDpJdrW50kHEDLg0D1Wnw8Ul80 SHVxja/YxvCTB0ea7chfwYGhIBN+uMeYeaBTR6Hp1JU65ywtGG4ZkK10TFH9GMVi wnIai65czl8Q187TD4cFXmsNDnuIB/RgVQmNxBx6DHJT8dG68id298lCTx47xJdk xWKcDv48fYjEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAmabtTcQHGFy bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSA8uBACADZbJVCX48XoosUbS8ynBqQoU smXPLmiXIIx+rGIa8YeeJh7w7kZd3bJZRuefDR+O21vnsyslxsDZtF/nJfszRR0n NIe+7yhGASyjikfzzK0TLsmbIPPbXII+wpE2iXjZq5dZHSxsbEt9ZcQRtsFmgVQE 5dIQSiLLvh39S/7hLA== =LIVo -----END PGP SIGNATURE----- --=-=-=--