Re: Effectively criticizing decisions you disagree with in Debian
Joel Rees <joel.rees@gmail.com> writes:
>> On Tue, Sep 23, 2014 at 7:16 AM, lee <lee@yun.yagibdah.de> wrote:
>>
>> 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.
Hmm. So linkage is a result of complexity, and implicity is a result of
undeclaredness (or unawareness of declaredness).
That means by trying to combine (existing) stuff with other stuff to
make things easier than (re-)inventing the wheel, you actually make
things more difficult because they are becoming more complex. If you
were to (re-)invent the wheel in order to /not/ make things more
difficult, you could still make them so complex that you could as well
use (existing) stuff because it makes things easier for you and no
significant difference in complexity.
In any case, you must reduce complexity in order to avoid implicit
linkage, because even declaredness in itself (or the problem of being
aware of the declarations) can become so complex (or difficult) that it
can make things difficult. Since you cannot make things less complex,
the concept of implicit linkage has been forgotten.
Is that about right?
If it is, we can't seriously object systemd, can we?
--
Knowledge is volatile and fluid. Software is power.
Reply to: