Re: Effectively criticizing decisions you disagree with in Debian
On Tue, Sep 23, 2014 at 7:16 AM, lee <lee@yun.yagibdah.de> wrote:
> 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?
As an example.
If you call a read() function in a C program, there are a bunch of
global variables and constants and types, etc., that you do not
explicitly reference in your call -- buffer size and count, the
location of the buffers, etc. Yes, most of them are explicitly
declared somewhere, or explicitly allocated at run-time, but you don't
see them in the call itself. This is one kind of implicit linkage.
I once considered a language where every such call would have to
explicitly declare all globals and side-effects, etc. It's not
possible. Still, reducing the number of globals is a good thing.
Another kind of implicit linkage is undeclared "magic" constants. For
instance, during the early days of PC-DOS, the buffers in the I/O
system were assumed to be either 128 bytes or 256, and everyone who
worked with the code knew that, so no one bothered to actually declare
it as a named constant. You just knew that, if you saw that number, it
was probably the buffer size. We don't see many of those any more.
In fact, we go a little overboard, defining named constants that never
get used, and the namespace clutter becomes another problem, and can
induce subtle bugs of its own, which is part of the reason for wanting
to be sure that everything you use is declared where you think it is.
Protocols are another. In early computer systems, there was often an
expected order of procedure:
When reading, allocate and clear the buffer first,
then check that the DMA controller is not being used and wait if necessary.
The DMA controller has it's own set of rules: maybe you have to set
the address before the count, or maybe you have to set the count first
and the buffer after, etc.. The order of these things should be
encompassed in subroutines, but sometimes there are optional steps,
and until callback routines became more common, you generally
(manually) copied template code to be sure you followed the protocol.
Even now, you may have a call-back routine to pass, and no clues as to
what that callback is supposed to do.
There are other kinds of implicit linkages, basically it's all the
stuff that you're expected to know when reading, modifying, or using
the code, but isn't written down in front of you anywhere, or is so
hard to find that looking it up is going to cause schedule slip.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Reply to: