Re: Effectively criticizing decisions you disagree with in Debian

[lee <lee@yun.yagibdah.de>]

Joel Rees <joel.rees@gmail.com> writes:

> (2) When I was a college student, when we talked about modularity, we
> talked about something called "implicit linkage". I don't know what
> the current term for it is, but it is the generalized problem of
> global constants, variables, protocols, and design patterns,
> especially those which are never formally declared.
> [...]
> In other words, the old adage that "A computer only does what you tell
> it to." no longer applies when implicit linkage is high.

Thank you for all the good points you're making!

I'm not sure if I understand what "implicit linkage" means.  I think it
was Slavko who, IIUC, pointed out that a bug otherwise minor or not
noticeable in some part of an "entangled conglomerate" (of software, in
this case) has better chances to cause trouble (and will be very
difficult to track down and to fix), the more entangled the conglomerate
is and the larger the conglomerate is.

This may kinda correspond to the saying that a chain isn't any stronger
than it's weakest link.  The effect is also that the computer doesn't
seem to do anymore what you tell it to.


But implicit linkage?  That software depends on (or: needs to be
entangled with) other software (in a conglomerate of software) doesn't
seem to fall under implicit linkage but under "explicit linkage":
Software intentionally entangles itself with other software.

I could guess that implicit linkage might refer to side effects of
intentional entanglement which may be undesirable or may occur without
being noticed (until a problem shows up which then might be hard to
track down and to fix because there are unknown side effects due to
implicit linkage caused by broken design).  Or does it refer to
unintentional entanglement (and its side effects)?  Or what is it?


-- 
Knowledge is volatile and fluid.  Software is power.