Talk Like A Duck: Tag psychology

Sapir-Whorf

Rick DeNatale — Mon, 11 Jun 2007 16:32:00 -0400

Recently, I’ve seen the Sapir-Whorf hypothesis used to motivate new spins on old ideas, such as behavior-driven design. For those unfamiliar with Sapir-Whorf it comes from the school of linquistic determnation, and taken to the extreme posits that a person’s language determines the way he or she thinks.

I’m going to post some thoughts about bdd soon, but this appeal to Saphir-Whorf reminds me of an experience I had about 10 years ago.

At the time, I was on a tour of eastern Europe for IBM. Our team was giving presentations on IBM software development products to developers in the former Soviet Bloc. I found myself in a hotel bar in Budapest with Muriel, a lovely young Frenchwoman who I’d met some months before and who was also one of the speakers. I’d decided to try to recover my old high school French which had been “rusting” for about 20 years. We had had several discussions about the French language and how it related to English. She had done a couple of overseas assignments with IBM in the US previously, and had worked in Connecticut with someone who had grown up in Brooklyn, which resulted in an amazingly charming and unique accent when she spoke English. We remain good friends to this day.

After a short time we were joined by another IBMer who was an American on assignment in Paris.

Flashback

I’d met him earlier in the day, when we were preparing for the next days session with the help of sevaral local IBMers. He had needed help in editing his Freelance presentation (I guess his secretary normally did this for him), and Muriel had done it using a Thinkpad borrowed from one of the Hungarians.

After she had finished, she closed Freelance to reveal that the machine was also running Microsoft Word. Mr. American in Paris went ballistic, since IBM had recently acquired Lotus. He couldn’t understand this treason, why was the guy not using Ami Pro? The answer was that Ami Pro didn’t yet support the Hungarian language.

This wasn’t enough to satisfy our friend, and the Hungarian went away shaking his head.

Back to the Bar

So our friend showed up and told us that, although he’d been in Paris for nearly two years, he hadn’t bothered to even try to learn any French. His theory was that there was no need since “everyone you work with speaks English anyway.” Now he exposed himself as a lingustic determinist, “and people who speak languages other than English can’t form certain thoughts.”

Oh really!? I said, like what?

“For instance, there’s no way to say “I like you in French.”

I shot an amused look at Muriel, we’d been talking about that very thing in the recent past. Those with a surface “knowledge” of French think this because the verb “Aimer” means both “to like” and “to love.” If you want sweet-talk a girl you say “Je t’aime.” Which every high-school French student, and ever sailor on shore-leave in a French-speaking port knows means, “I love you.” So they figure that there’s no way to say “I like you” since “aimer” is already taken.

But of course there is. French isn’t the “language of diplomacy” due to a lack of expressiveness. One way to say I like you is “Je t’aime bien” which seems odd to some since the “bien” strengthens a verb. That girl you’re trying to sweet-talk migh reply with “Je t’aime bien, mais je ne t’aime.” or “I like you but I don’t love you.”

And the Japanese don’t have a word for “no” which is why they can’t be impolite.

Again, this is patently false. Anyone who watched the old mini-series whould now that one of the first words Anjin-san learned was ie which means an emphatic no. The Japanese have lots of ways of saying no, or expressing variations of that thought, with various levels of politeness.

He went on to express several similar thoughts, but my amazement at his naiveté soon turned to boredom, and I tuned him out.

Does Language (Determine|Influence) Thought?

The Sapir-Worf hypothesis in it’s strongest form, and more generally, linguistic determinism, are nothing if not controversial amoung psycho-linguists. While there is some experimental evidence that language might have some influence on thinking, it doesn’t seem to be as pervasive as Sapir-Worf would predict.

Language, Expression, and Communication

It does seem evident to me that language affects the way thoughts are expressed, and that this difference in expression can hinder communication.

Take the expression of “I like you” in French. Not understanding the subtleties of expression might lead to a slapped face! I’m not sure about this, but my theory about “Je t’aime” vs. “Je t’aime bien” is that the two phrases might be related to teachings in the Catholic church. When I learned of the distinction, it brought back a memory from parochial school. The parish priest was visiting the classroom, and the teacher, a nun, asked him to explain the difference between “like” and “love.” He said that like was more than love because “I have to love you, but I don’t have to like you.” Because we might be talking to someone whose native language lacks the subjunctive case doesn’t mean that she can’t think hypothetically, and when she is trying to talk hypothetically we might not understand how she translates from her native language into English. It actually disproves my “ugly American friend’s” belief that since everyone needed to do business with already speaks English, there’s no need to make any effort to understand their language.

Now Back to our Regularly Scheduled Program

So what does all this have to dowith the usual subject matter of this blog?

The answer is that this mismatch between thought and expression leads to misunderstanding even in technical matters.

Someone whose ‘native language’ is strongly typed can have a hard time understanding the expressive power and idioms of a dynamically typed language such as Ruby or Smalltalk, and those without knowledge of Java or C++ can have a hard time understanding those guys, and arguments can proliferate because words denote slightly different concepts in various programming languages.

Different “methodologies” can sprout up as different groups of developers independently discover the same or similar techniques and give different names to the same concept, or the same name to different concepts, or a guru decides that a vocabulary shift is just the thing needed to explain something to a group with another mode of expression. Some of have been using agile techniques before they were agile, or even extreme.

And it can be languages vs. methodologies. I like to use the term “behavior” the way Smalltalk uses it, as an abstraction for an object which contains the methods of other objects (i.e. classes and metaclasses). I’m afraid that with the rising popularity of behavior-driven development in the Ruby community, with a different meaning of behavior, I’m going to have to find a new term.

But more on BDD here soon.

Are you aiming at the right bug?

Rick DeNatale — Mon, 12 Mar 2007 12:26:00 -0400

How many times has this happened to you?

You have a really tough bug which defies all attacks. Finally after pondering it for hours, or days or maybe more, you realize that the symptoms you are seeing aren’t due to the posited bug at all, but are really something else.

Some examples.

On ruby-talk, I’ve been trying to help someone who was having problems making Net::SMTP work. He had some code which included:

smtp.open_message_stream('sender@mail.com', ["dummy@dummy.com"]) do

And which was working, except that he really wanted to send an email to an address held in a variable rather than “dummy@dummy.com” He was getting an error if he used ‘a’ variable for the recipient address, and wondered why the array couldn’t take a variable.

At first it looked to me, based on the examples he was giving that he was trying to pass the name of the variable as a string, and I suggested that he just change that parameter to [email]. But he said that that still didn’t work (actually he’d already tried it.

I was getting frustrated, until he rephrased something that he had briefly mentioned in his intial post, that the error he was getting was a ‘tainted sender’ error. The problem was really that he was getting the object referenced in the variable from a web form, and the framework code he was using was, rightly, tainting these values as a protection against security exposures. There was no problem with passing values. The solution was to untaint the object after sniff-testing it.

I’ve done similar things in the past. My theory of what’s wrong becomes an idee fixee which blocks me from seeing the truth.

Two more (colorful) examples:

Some years ago I was building an application in Smalltalk which allowed for boxes to be drawn with connecting lines which were anchored to the boxes so that they moved when a box was moved. The kind of thing you need for a pert chart or other network diagram. Everything was working until I changed the lines into separate objects, when the lines just disappeared. I kept trying to figure out why the line objects weren’t drawing, until it finally dawned on me that they actually were drawing. I was using xor to draw them so that I could easily erase them in order to animate them when the boxes moved. The only way I figured this out was because in desperation, I changed from using a black line to a red one, which allowed me to see the line being drawn, then erased as the color changed from red to cyan. The problem wasn’t in the line object at all but in the animation code which was drawing then erasing the line.
More recently, I’ve been playing with a Ruby application which is a Sudoku puzzle assistant, as an exercise in learning RubyTk among other things. It displays the values of the initial squares given in the puzzle in black, and uses blue for squares which you have set yourself. The model object for the square has a boolean instance variable named initial which is set when the puzzle is initially entered so as to show this difference. Once the application is set in ‘play’ mode no other squares should have this variable change.
I’d gotten pretty far along with this, including having commands which search for constraints on the values of squares, then apply those constraints, etc. I’d recently improved the ability to save the puzzle in a file. My first pass just saved the initial values, more recently I’d added saving the state of the solution as well.

I was happily playing with testing, when I noticed that in one case finding a contraint, changed one of the squares from black to blue. I spent several days trying to figure out why the initial status of that square was being changed. I pulled out all kinds of Ruby-foo to figure this out. I made sure that the variable was only accessed by a reader and writer accessor methods so that I could print a backtrace when it changed, but I never could find the culprit.

Of course the punchline was that there was no such culprit. I finally realized what was happening when I, for what was probably the hundreth time, started the application and read in the test file containing the puzzle. That’s when I realized that the square in question was actually not one of the squares which had a value given in the initial puzzle. The real bug turned out to be that, non-initial squares weren’t being drawn correctly when the puzzle was read. It wasn’t until I did something which caused that square to be re-displayed that the value got drawn in the correct, blue, color.

Gerry Weinberg had a lot to say about such things in his thirty-six year old classic book “The Psychology of Computer Programming.” He calls this psychological set, which is the tendency for us to see what we want/expect to see. It’s what makes proofreading hard, we tend to mentally read a word like ‘dack’ as if it were printed ‘duck.’ He describes an experiment which showed that commented code can be harder to debug than uncommented code because most comments describe what the code is supposed to do rather than what it actually does.

So the next time you get stuck on what seems like a hard debugging session, step back and consider whether your minds-eye or your pre-conceptions are blocking you from considering the real reason for the symptoms you are diagnosing.