implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

[lee <lee@yagibdah.de>]

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

>> 2014/09/25 9:15 "lee" <lee@yun.yagibdah.de>:
>>
>>> Joel Rees <joel.rees@gmail.com> writes:
>>
>>
>> Hmm.  So linkage is a result of complexity,
>
> What is complexity?
>
> Complexity is not a simple topic. :-\
>
>> and implicity is a result of
>> undeclaredness (or unawareness of declaredness).
>
> Sort of, but not quite.
>
> I would rather say,
>
>     Implicitness is the lack of explicit declaration at the point
> where the linkage is expressed (or occurs).
>
> but I'm not sure that would be universally well understood, either.

So implicitness isn't a result of something but a lack of explicitness.
Too much explicitness isn't good, either, because it'll get into your
way.

You could as well argue that linkage is basically a bad thing and
therefore should only be accepted for instances where it has significant
advantages which outweigh the disadvantages.  At least we have a
tautology here.

> Generally, reducing complexity and reducing linkage are related, but
> not necessarily. The degree to which linkage is implicit, or to which
> entanglement is hidden, is not necessarily dependent on the degree of
> either complexity or linkage. These can be independent variables,
> depending on the case in question. In some cases, you can even make
> them indpendent variables, when they didn't start out that way in your
> analysis.

Hm, true ... Less linkage is easier to hide than more linkage.  It makes
me think of a simple perl script.  Such a script probably has an
unbelievable amount of implicit linkage. For example:

perl -e 'print scalar localtime, "\n";'

>> Since you cannot make things less complex,
>
> I'm not sure what you're trying to say.
>
> If you know you can make things more complex, you know that there must
> be things that can be made less complex.

The less complicated things tend to be deprecated and to become
obsolete.

25 years ago, computers didn't have sound cards.  You could possibly add
one, making your computer more complicated both in terms of total
complexity of hardware and software.  Nowadays, a replacement for a
sound card is built in.  Making things less complicated would mean to
omit or to remove the sound cards and their replacements.  Who wants to
do that?

> There are several kinds of complexity.
>
> One is purely subjective -- perceived complexity: "It's different, so
> it's complicated." or "I don't understand it, so it's complicated." We
> can talk about the parsing of a problem by the human brain, but it
> wouldn't help yet. We should set perceptions of complexity aside here.
>
> If you have a device with 100 inputs and 100 outputs, that's going to
> look complicated, right? But if all the inputs just feed directly to
> the outputs, it's not really all that complicated after all. This is
> one kind of complexity. Analysis is straightforward.
>
> If some of the inputs are inverted or amplified, that's a little more
> complicated, but it's the same kind of complexity. Also, if some of
> the inputs combine with others, so that some outputs are a function of
> multiple inputs, this is a bit more complicated, but it's still the
> same kind of complexity.
>
> If some outputs feed back into their own inputs, this changes the kind
> of complexity. Small circuits aren't too bad, but if you have even 10
> inputs and 10 outputs, and you have some outputs that are a function
> both of themselves and their own inputs, analysis gets difficult in a
> hurry. If all ten are fed-back and mixed with other inputs, you have a
> circuit that is more complex (and more complicated) than the simple
> one with a hundred inputs and outputs that don't feed back.

How is this a different kind of complexity?  It may be more complexity,
yet it's still the same kind.

> If you can take the device with feedback and split it into five
> separate devices, where there is no interconnection between the five
> devices, even if there is feedback within individual devices, the
> resulting collection of devices is generally much easier to analyze
> than the single device with ten inputs and ten outputs with feedback.
> And much easier to design and build correctly.

It won't be able to do the same things as the device with 10 inputs and
10 outputs because you have removed the interconnections.  Each device
is on its own, with the same kind of complexity.  Only each device is
less complex, and the whole thing is less complex because you removed
all the linkage.

> Programs and program functions are similar, the inputs being input
> parameters, and the outputs being the result, including side-effects.

I guess there can be side effects through implicit linkage and others.

>> If it is, we can't seriously object systemd, can we?
>
> Well, that's what the pro-systemd folks seem to be saying, isn't it?

They don't realise that they employ too much linkage.

That it still works doesn't mean anything.  I'm finding this
point particularly interesting.  It's easily overlooked ...


-- 
Hallowed are the Debians!