Re: [PATCH] The Guile junk drawer and a C plea

[Dr. Arne Babenhauserheide]

Attila Lendvai <attila@lendvai.name> 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.
>> 
>> 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 ‘define-module2’ (to be used instead of the
>> (deprecated) ‘define-module’) with the new semantics. Since their
>> implementations would share almost all code, there wouldn’t be
>> serious implementation costs(*). The only significant downside I see
>> here is that ‘define-module2’ is a rather uncool name, but that’s 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.

Do you know that the Broken Window theory has been debunked?
https://cssh.northeastern.edu/sccj/2019/05/21/researchers-debunk-broken-windows-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’s right when seen *in isolation*
instead of the more complex one that’s 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’s used in AI stuff that I didn’t understand before. Before 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.¹

By breaking many of the tools that took a deep dive on Python to
actually follow the advertised best practices, these best practices
changed.

¹ I checked whether I’m wrong after writing this — because I might have
  been: I’m far from all-knowing, and I mostly see Python from the
  sidelines these days: I stopped being an enthusiastic Pythonista
  around 2013. But here’s a representative article about uses of Python:
  
https://www.coursera.org/articles/what-is-python-used-for-a-beginners-guide-to-using-python
  - Data analysis/ML (thin veneer)
  - web development (framework²)
  - automation/scripting (thin veneer for IO and subprocesses)
  - testing/prototyping (thin veneer for compiler/bad idea³)
  - everyday tasks (thin veneer)

² 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’t stable either, limiting your own code keeps maintenance cost
  low.

³ 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 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.

> 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’s important to 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’s 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 <lassi@lassi.io> 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’t 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
--- a/doc/ref/tour.texi
+++ b/doc/ref/tour.texi
@@ -210,6 +210,15 @@ processing or command line parsing.  Additionally, there 
exist many
 Guile modules written by other Guile hackers, but which have to be
 installed manually.
 
+Most provided modules use one of three different prefixes:
+
+@itemize @bullet
+@item @code{ice-9} includes guile-specific modules: the standard library of 
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’s: 
@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
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

signature.asc
Description: PGP signature