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

'define-module2’ and ‘define-module’ aren’t Turing tarpits:

• Neither are Turing-complete (unless perhaps you do fancy stuff with merge-generics and custom (GOOPS) method metaclasses, but then it was your own choice to turn it into a Turing-tarpit).
• Both are (relatively speaking) easy to use. A slight difficulty for beginners is determining where in the file system to put the module (hence the relatively qualifier), but both define-module and define-module2 have the exact same problem, and AFAIK other programming languages aren’t any better at this (hence ‘relatively’).

‘define-module2’ is not a broken window, it is a fixed window. Neither is ‘define-module’, it would be slightly outdated in its precise semantics (and hence not recommended), but it does work decently.

The broken window here, is breaking the backwards incompatibility by _not_ doing ‘define-module2’ or the like. (Doesn’t need to be ‘define-module2’ per se, other methods for preserving compatibility exist as well.) ‘define-module2’ 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 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.

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 ‘define-module2’. That ‘2’-suffix can be quite useful (for compatibility).

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

(*) In the past I’ve sometimes argued for _not_ preserving backwards 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 ‘define-module2’. The only thing that comes close is ‘badly chosen name for abstractions’, but well, ‘define-module2’ would define a module, and it is the second (*) incompatible version of this method to defining modules. As such it seems a pretty decent choice of name (just a bit boring).

(*) or maybe third, I’m assuming things here about Guile <2.2 that I don’t actually know, the hypothetical ‘define-module2’ / ‘define-module’ 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.

Nowhere did I say anything about not properly deprecating ‘define-module’.

Best regards,

Maxime Devos