The Law of Inconsistent Assumptions

The law of inconsistent assumptions (a pseudo-philosophical rant)

There is a pervasive circumstance in human language (in general) and programming languages (in particular) where communication breaks down because people are using the same "words" but with subtly (or overtly) different understandings of the context.

This circumstance is called "The law of inconsistent assumptions" (at least that's what I'm calling it here).

I refer to it as "the law" partially to imply that this circumstance cannot be completely eradicated, (absent some 'telepathic' mode of communication); and also to imply that it is always there, behind the scenes, (like gravity). Just like gravity, "the law" can be useful if recognized (help explain planetary motion), or harmful if ignored (make you go "splat" when trying to fly like superman).

Why this matters: from a perl point-of-you

When you get a bunch of knowledgable people of good will and disposition together, you can notice some remarkable creativity. You can also notice that some discussions seem to drone on with people 'talking past one another'. When you realize it is not because of ill-will or ignorance of the participants, you realize this is one manifestation of "The law of inconsistent assumptions". When you recognize "the law" taking effect, you have acquired an opportunity over a cognitive stumbling block, and you are going to be a better programmer, teacher, and communicator because of it.

Straightforward Examples

Here are some examples of "the law" in perl programming terms.

Throwaway Warning Messages

### fee_file.pl
use strict;
use warnings;

$main::fee   = 0xfee;

__END__
Produces the warning message:
Name "main::fee" used only once: possible typo at ...
[download]

The previous example correctly sends a warning based on the assumption that the name main::fee should appear at least twice in a single script.

### foo_file.pl
use strict;
use warnings;
require "fee_file.pl";

my  $foo;
print $main::fee;
print $foo = 12;
__END__
Produces the warning message:
Name "main::fee" used only once: possible typo at ...
[download]

The previous example sends a spurious warning message because the former assumption breaks down ... incomplete assumptions about what constitutes a "single script".

Language Comparision Debates

Someone once declared

Perl guarantees that for virtually every time you access a variable, you will have to type at least one more character (and hit Shift!) than Python.

... and then went on to compare ..

### perl
$foo = 1;

### python
foo = 1
[download]

... but left out the comparision ..

### perl
print "Hello $foo."         ### 19 chars

### python
print "Hello "+foo+".",     ### 23 chars
[download]

... the first comparison assumes a limited definition of 'accessing a variable' and ignores that the '$' symbol is actually a *command*, not just some throw-away extra keystroke that has no relevance whatsoever. Thus, a more complete comparison would be the $ command versus the "++" command.

Vigorous Areeing

A particularly good example of "the law" (in terms of human communication) can be found at this node where the participants (knowledgable people) nevertheless seem to be "disagreeing" but in actuality probably agree quite a bit, but the buzzwords GUI,CLI make communication difficult.

The bottom line

These examples are not even the tip of the iceburg, "The law of inconsistent assumptions" is everywhere. As you and I begin to notice it more and more, the benifits will follow.

Comment on The Law of Inconsistent Assumptions Select or Download Code

Replies are listed 'Best First'.
Re: The Law of Inconsistent Assumptions by hardburn (Abbot) on Oct 19, 2004 at 15:38 UTC
In one of my writing courses, I heard an excelent idea of how to combat this tendency. After the other person is done speaking, you give your own interpretation of what they said. The other person will then either correct you (and then repeat the process), or you go on with your own point. It might make for a very redundant means to communicate, but it's more robust as a direct result. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]
Re^2: The Law of Inconsistent Assumptions by pg (Canon) on Oct 19, 2004 at 17:36 UTC
This is actually what I have been doing in my real programming life, and it has been proved to be very efficient. When I discuss with one person, or a group of people, for each key point, I always rephrase what I heard (obviously I interpreted it already), and ask the person to confirm. At the end of discussion, I will again recap all what I got in my own words, and ask everybody in the room to agree or disagree. By doing this, you largely reduce the chance of misunderstanding.	[reply]
Re^3: The Law of Inconsistent Assumptions by DrHyde (Prior) on Oct 20, 2004 at 09:01 UTC
I even go a little further. Often when I get a written spec from a client, I rewrite it in my own words, and get them to sign off on it. It catches some quite nasty errors in interpretation.	[reply]
Re: The Law of Inconsistent Assumptions by EdwardG (Vicar) on Oct 20, 2004 at 07:35 UTC
Yes indeed, and this law might also be known as talking at cross purposes. Cognitive Behavioural Therapists have long proposed Active Listening as a partial solution, but of course this only mitigates the problem, which can be deeply rooted, such as with degrees of Autism (Asperger's). And it is very difficult to teach a person to accurately detect non verbals if it doesn't already come naturally to them. Still, I like the presentation of the issue as a law since it feels more manageable that way. ++	[reply]
Re: The Law of Inconsistent Assumptions by Corion (Patriarch) on Oct 19, 2004 at 15:50 UTC
Just a note - I prefer the `sprintf`-style notation of string interpolation in Python, but there are also other, less cumbersome ways: `print "Hello",foo,"." # not quite the same output but close enough print "Hello %s." % (foo) # printf-style interpolation` [download] Manually concatenating strings is soo low-level :-)	[reply] [d/l]
Re^2: The Law of Inconsistent Assumptions by SpanishInquisition (Pilgrim) on Oct 20, 2004 at 20:02 UTC
Obligatory Ruby example: `puts "This post was brought to you by the number #{ x + 75 / y} and th +e letter #{q}";` [download] Arbitrary code execution, variables, anything. If you want printf, Perl has a nicer printf than the example Python syntax. Why? It looks like printf and is therefore nice and short :) Regardless, a language is not about keystrokes, it's about style. Python is too wordy for me, and not automagical enough.	[reply] [d/l]
Re: The Law of Inconsistent Assumptions by Juerd (Abbot) on Oct 19, 2004 at 17:40 UTC
require "fee_file.pl"; Big red flag with sirens and flashing lights! :) See Including files. If a module had been used, this warning would not have been there. Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }	[reply]
Re^2: The Law of Inconsistent Assumptions by thor (Priest) on Oct 19, 2004 at 23:38 UTC
Nevertheless, require is still valid syntax...and perl knows about it. That's like putting your hand on the stove and asking why your hand is hot. thor `Feel the white light, the light within Be your own disciple, fan the sparks of will For all of us waiting, your kingdom will come`	[reply]
Re: The Law of Inconsistent Assumptions by mexnix (Pilgrim) on Oct 20, 2004 at 14:00 UTC
I run into this A LOT, though, with me, it appears to happen more often with "intelligent-but-ignorant" people. (ie. my boss) One of the words that really seems to throw them off is "database", suprisingly. But yeah, when explaining what I'm working on, or trying to incorporate what they want into a program, normally results in horribly long conversations and gnashing of teeth. The only other place I've seen this in action is with my wife. (hehe) "The law of inconsistent assumptions" is responsibly for most of our small arguments, but as we begin to recognize it more, often these "arugments" can be avoided.	[reply]
Re: The Law of Inconsistent Assumptions by ihb (Deacon) on Oct 20, 2004 at 15:30 UTC
The previous example correctly sends a warning based on the assumption that the name main::fee should appear at least twice in a single script. That statement is a bit too vague and I'll explain why below. The previous example sends a spurious warning message because the former assumption breaks down It's only spurious if it is based on the assumption you say it's based on, but as I'll come to, it's not necessarily based on that assumption. incomplete assumptions about what constitutes a "single script" I neither agree or disagree, but I more disagree than I agree. I'd stretch as far as saying that you may have an incomplete assumption of what the warning means, and that's why you think it breaks down and you think a spurious warning is emitted. What the warning really means, but doesn't clearly say, is 'Name "main::fee" used (i.e. seen) once (at compile-time)'. It's got nothing to do with where the variable is seen, but when. Your program is one thing during compile-time. Your program can be another during run-time and can change infinately many times during run-time. The warning is looking at what your program is during compile-time. If you put a `BEGIN` block around your `require()` the problem would've been solved and the warning goes away, as the variable is now seen more than once during compile-time. The problem is no different from doing `eval '$main::fee = 0xfee'`. Perl has no way of knowing that you use that you use `$main::fee` since the usage of `$main::fee` is not a part of your program yet. `ihb` See perltoc if you don't know which perldoc to read! Read argumentation in its context!	[reply] [d/l] [select]
Re^2: The Law of Inconsistent Assumptions by dimar (Curate) on Oct 20, 2004 at 20:08 UTC
Your point regarding the 'compile time' versus 'run time' distinction is a point well-taken. From a technical perspective, your point helps to identify and zero in on a key issue. From a communication perspective, it helps to demonstrate how "the law" (TLIA) can creep into even this very discussion. Perl has no way of knowing that you use ... $main::fee since the usage of $main::fee is not a part of your program yet. Although the whole "throwaway warnings" example is not my favorite, the point I hoped to illustrate was precisely that people can have "inconsistent assumptions" about what constitutes "part of your program yet." One person can take the (admittedly more complete) assumption that a program is "finished" only after it has compiled, run and terminated. Another person can take the (admittedly more simplistic ... and perhaps even deeply flawed) assumption that a program is "finished" once he or she has written all the source code and saved it to disk. Because of TLIA, I guess the point is, this kind of "disagreement" (aka divergence of assumptions) does not even get out into the open (what does the word "finished" mean) until: 1) someone proactively asserts "active listening"; or 2) something more "messy" like a contract dispute arises. I guess the other point is, TLIA is something I (and perhaps others) need to be more keenly aware of in general...	[reply]
Re: The Law of Inconsistent Assumptions by eric256 (Parson) on Oct 20, 2004 at 16:02 UTC
In the subtle differences category I have a real life example of my own. Well I have many, but one happened the same day you posted this. It should be noted that chat and posts like this drasticaly increase the confusion because of the lack of non-verbal cues as to a words meaning. My example happened in an IM session while helping a fellow programmer debug. At one point he said "i can't be bothered to fix that", which reading now doesn't sound offense, but at the time, in the context, it sounded to me like a great insult. I had spent my time helping him and then he suddenly can't be bothered. I see it as a good example of this law in work because even now I don't see the insult. Communication is such a treaky beast, in my head this seemed like a great post and now it has dwindled to nothing more than a rambling. Just my 2 cents as usual. ___________ Eric Hodges	[reply]
Emotionless Computers (was: Law of Inconsistent Assumptions) by perlcapt (Pilgrim) on Oct 23, 2004 at 13:38 UTC
As a social group, we (pronoun open to interpretation) may be finding certain comfort in knowing that the computers with which we communicate may misunderstand our meaning, but never misunderstand our feelings. Feelings are never a factor. This is a much simpler set of unknowns for communications than with humans, right Mr. Spock? Perhaps the computer's of lack emotional interpretation is why we spend so much time with them. But then, when we get into discussions with other humans concerning computers or using computers (and networks) we are surprised by the emotional reactions. People associated with computers are emotional! Going back to the original thread of this discussion: Thank goodness the article, The Law of Inconsistent Assumptions, reminds us that it is a predictable phenomenon. Look how long it took the Western world to codify the predictable phenomenon of gravity despite the fact that people had been falling down and hurting themselves for millenia. The "Active Listening" mentioned in Re: The Law of Inconsistent Assumptions is like having a pillow that makes the falls more comfortable and with less injury. Good Stuff. perlcapt -ben	[reply]
Re: The Law of Inconsistent Assumptions by zentara (Archbishop) on Oct 20, 2004 at 14:24 UTC
There is a pervasive circumstance in human language (in general) and programming languages (in particular) where communication breaks down because people are using the same "words" but with subtly (or overtly) different understandings of the context. Yes I have pondered this for a long time, and found that the "wider the scope of the word", the more inconsistency there is. As discussed here, it is relatively narrow in scope, talking about programming terminology. But it really becomes difficult when the scope is wide, as when you are talking about things like soul, life, existence, etc. Then it can take hours(even years) of interactive discussion before a group can agree on what the words ACTUALLY mean. This gets compounded by the "unique emotional feeling evoked by each word", ....I call it the "You havn't walked all the way in my shoes" Collory. :-) I'm not really a human, but I play one on earth. flash japh	[reply]
Re: The Law of Inconsistent Assumptions by qumsieh (Scribe) on Oct 22, 2004 at 20:54 UTC
The previous example sends a spurious warning message because the former assumption breaks down ... incomplete assumptions about what constitutes a "single script". Not quite correct. Lexical variables don't live in the symbol table, they have their own scratch pads. Thus: `my $foo;` [download] and `$main::foo;` [download] are two different variables, and hence the warning msg.	[reply] [d/l] [select]