guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: The Guile junk drawer and a C plea


From: Attila Lendvai
Subject: RE: The Guile junk drawer and a C plea
Date: Sat, 20 Jul 2024 09:34:22 +0000

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

the longer version:

you do not see how many potential contributors end up never touching the 
codebase 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 few 
discussions about how and why we got our impressions and made our decisions.

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.

these things give a quick impression about how much effort and annoyance it 
would be to delve into the codebase, and how quickly the invested effor would 
yield a bugfix, or a new feature, or answers to questions. and people decide 
based on this impression. and there's practically zero feedback about the 
number of people deciding *not* to contribute based on such impressions.

in my understanding of how these things work, this is very much *not* a 
non-issue.

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.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“He alone is great and happy who fills his own station of independence, and has 
neither to command nor to obey.”
        — Johann Wolfgang von Goethe (1749–1832), 'With the Iron Hand' (1773), 
Act I




reply via email to

[Prev in Thread] Current Thread [Next in Thread]