That's What I Call a Compliment: A Hasidic Parable by MC Complete

 There once was a commoner transporting a lot of heavy packs on his donkey. Suddendly the donkey stumbled and all the packs fell off. Oh no, thought the commoner. It will take forever to reload this donkey. Just then, he saw his friend running over to help him. Together, they were able to reload the donkey in half the time. The commoner was so grateful to his friend. "You're the king," he said.

The next day, the commoner went to a show where a musician was playing the harp. The music was so beautiful and so skillfully played that it almost brought the commoner to tears. After the show, the commoner ran up to the musician. "You're the king!" he said.

The next day, the commoner went to pick up a shirt from the tailor. He couldn't believe his eyes. It looked as good as new. "You're the king!" he said to the tailor.

The next day, the palace guards grabbed him and dragged him to the throne room. "What did I do?" he asked the king.

"Nothing," said the king. "I just want you to sing my praises."

"But I can't sing," said the commoner.

The king rolled his eyes. "You don't need to sing," said the king. "Just say something nice about me."

"You're the king!" said the commoner.

"Excuse me?" said the king.

"I said, you're the king."

"Off with his head," said the king.

"What?" said the commoner. "What did I do?"

"Obviously I'm the king," said the king. "That's not a compliment, that's just stating a fact."

The executioner was summoned. The guards put the commoner's neck on the chopping block. The executioner raised his axe. "Wait, wait!" said the king.

"What now?" said the executioner.

"This idiot deserves to die," said the king. "But I'm going to let him go home."

"Home?" said the executioner. "You're not even going to like throw him in the dungeon or something?"

"You heard me," said the king.

The executioner shrugged. "You're the king," he said.

The commoner fell to his knees and bowed. "Thank you, thank you, thank you!" he said. "You truly are a merciful king!"

The king smiled. "Now that's what I call a compliment," he said.

Promises

In Pirkei Avos 1:15, Shammai Hazaken says, "say little and do much."

Devarim 23:23 says, "if you don't make vows, you won't end up doing sins." (Meaning, you won't end up doing the sin of breaking your vow.)

We learn from this that keeping promises is good, and making promises is bad.

A Plague of Sound

 Why didn't the dogs bark on the night of the Exodus?

I never thought about it much until recently. I'd usually assumed that what the Torah really means by saying that the dogs didn't bark was that the Egyptians didn't protest when the Jews sacrificed lambs. Earlier, Moses had predicted that if the Jews were to sacrifice lambs in Egypt, then the Egyptians would stone them, because the lamb was considered a god (Shmos 8:26). So I'd thought that the Torah was using a kind of hyperbole: when the Jews actually did sacrifice lambs, not only did they not get stoned, the Egyptians didn't even raise their voices in protest, and even the dogs didn't bark.

It also reminded me of the trope that often appears in ghost stories, that humans can't see ghosts, but dogs can (and the dogs usually bark at the ghosts). During the plague of the firstborn, the angel of death came to Egypt, so you might have thought that the dogs would have barked at him, but they didn't.

When you read the pasuk in context, however, a different explanation suggests itself. (It's Shmos 11:6-7.) The previous pasuk talks about the screaming and wailing that will take place in Egypt when the firstborn die. The lack of dogs barking seems to describe the silence (peace and quiet) that will prevail among the Jews. As if the plague of the firstborn is not only a plague of death, but also a plague of sound.

This makes an interesting juxtaposition to the previous plague, which was a plague of darkness, so in a sense, a plague of light, or lack thereof: "For all of the children of Israel, their was light in their dwelling places." (Shmos 10:23)

The Artscroll commentary on the Chumash says basically the same thing: "In sharp contrast to the grief and death that will engulf the Egyptians, the Jews will enjoy complete tranquility; not even a dog will bark or how against them."

Why Did Moshe Hit the Rock?

Moshe dies right before the Israelites invade the land of Canaan. The Torah makes it clear that this is not an accident; it's a punishment. What is it a punishment for? There are actually two versions in the Torah. The less familar one, stated in parshas Devarim, is that Moshe is being punished along with the generation of the desert for the sin of the spies. The one most of us are more familiar with is the sin of Mei Meriva, when Moshe hit the rock.

What exactly did Moshe do wrong in the story of Mei Meriva? There are actually multiple opinions about this, and the Torah does not say explicitly. Most of us assume that Moshe's sin was hitting the rock after Hashem had told him to speak to the rock; presumably the reason that this theory is so common is that it is endorsed by Rashi.

In this case, I find Rashi's position compelling. So let's assume that Rashi is right. Hashem told Moshe to talk to the rock, and Moshe disobeyed a direct order and hit the rock instead.

That raises a big question. What was Moshe's motive? Why didn't he just talk to the rock?

Another question -- not so big, but still a question -- why does Hashem say that Moshe (and Aharon) didn't believe in Him, and desecrated His name? I can understand how disobeying a direct order would lead to the punishment of not going into the land -- it's arguably not such a big punishment, Moshe lived 120 years -- but why would hitting the rock constitute 1. a desecration of Hashem's name and 2. a lack of faith?

To find out why Moshe might have hit the rock instead of talking to it, let's take a look at what he says to the Israelites right before he hits the rock. "Listen you rebels, from this rock, shall we bring forth water?"

Grammatically, this is a question. But what kind of question is it? It doesn't seem to be the kind of question where Moshe is actually asking for information. It sounds like a rhetorical question. Right?

Whenever there is a rhetorical question, there is an implied answer. What is the implied answer here?

One possibility is that Moshe is implicitly asking whether the Israelites want him to draw water from the rock. Maybe it could be rephrased as "Hey guys, want me to draw water from this rock?" in which case the implied answer would be "yes" -- Moshe knows that the Israelites want water, they've made that painfully clear.

But there's another possibility. Imagine that there's a natural disaster today that creates a water shortage in some area of the world. There's no running water, no water in the stores. Imagine a family where all the kids are whining and complaining to the father (or the mother) that they're thirsty and they want water. In a fit of frustration, the father picks up a broom and says, "What do you want from me? Do you think I can just hit the wall with a broom and water's gonna come out?" Maybe Moshe was saying something like that. "What do you want from me? Do you think I can just hit a rock and make water flow?"

The big difference between the story I just told and the story of Mei Meriva is that the father in the story has no magical powers and has no reason to believe that a miracle will happen. Moshe, on the other hand, was told by Hashem that if he talks to the rock, the rock will indeed bring forth water.

Which would explain why Moshe hit the rock and didn't talk to it -- he didn't want the rock to bring forth the water.

Which begs the question, of course -- why not? Why didn't he want the rock to bring forth the water?

In the story of Mei Meriva, the Israelites were asking for water. That's a reasonable request -- a very reasonable request. Water is one of our most basic needs. Without water, they might all have died. However, they didn't ask very nicely. They said "why did you take us out of Egypt" and other not-so-nice things. They started a riot. Without divine intervention, Moshe himself might have been killed.

This probably bothered Moshe very much. But somehow, it didn't seem to bother Hashem at all. Hashem didn't even condemn the Israelites' behavior. He just said "give them water" and He told Moshe how. At that point, maybe Moshe snapped. He didn't think they deserved water, at least not without a good talking-to.

If this interpretation is correct, it makes perfect sense that Hashem would say to Moshe (and Aharon, who was apparently in on Moshe's plan, though the Torah is coy on those details) that he failed to sanctify Hashem's name. In this instance, Hashem -- for whatever reason -- was focusing on performing the miracle of producing the water, which would be a spectacular show of power. Moshe tried -- and ultimately failed -- to get in the way of that.

Abstraction Considered Harmful (In Unit Tests)

If you were building an ALU, how would you test addition?  You'd probably write tests like

# Figure 1.
self.assertEqual(1 + 2, 3)
self.assertEqual(1 + (-2), -1)

etc. etc.  But those tests are exactly for having those numbers.  It's very specific to the use case.  What your ALU really does is add numbers, and so maybe that's what it should check?  So why not write a test like this:

# Figure 2.
for x in range(MIN_INT, MAX_INT):
    for y in range(MIN_INT, MAX_INT):
        self.assertEqual(x + y, x + y)

Now that test tests what your code does, not just specific use cases.  But there's an obvious problem: that test does absolutely nothing.  If there's a bug in the ALU, both expressions will return the same wrong answer, and the test will pass.  So how about a test like this?


# Figure 3.
def my_alternative_addition_function(x, y):
    # The best software arithmetic code ever

def test_addition():
    for x in range(MIN_INT, MAX_INT):
        for y in range(MIN_INT, MAX_INT):
            self.assertEqual(
                x + y, 
                my_alternative_addition_function(x, y)
            )

That code most definitely is testing something.  And it’s definitely better than the code in Figure 2.  It’s testing what the ALU does, not a specific use case.  So it looks like a pretty good test, right?

Maybe, but I would argue that there’s still a problem.  The trouble is that it’s very tempting to use similar procedures in my_alternative_addition_function(), so that the code in your “alternative” function looks very similar to the code that you’re effectively using in your ALU.  If that’s the case, then the code in Figure 3 is not really much better than the code in Figure 2; the bugs in your ALU are likely to be present as well in your “alternative” function.

Sure, if you (or someone else) later changes the ALU, then this test might catch the regression.  On the other hand, this test won’t catch the bugs in the first version of the ALU; also, when the test fails in the future, the code maintainer will be tempted to fix the test by “fixing” the alternative function.  After all, tests need to be updated when code changes, right?

What if you make sure that the code for my_alternative_addition_function() is totally different than the code effectively used by your ALU?  What if you use a different addition algorithm, or hand the test off to a third party who’s never seen your ALU design?  Would that be sufficient?

Maybe, but maybe not.  If the test fails, you don’t know whether the bug is in the ALU or in the alternative addition function.  And the temptation is always there to fix the test by “fixing” the alternative, even when the real bug is in the ALU, thereby breaking them both, and effectively putting us back where we started, in Figure 2.

That’s why the code in Figure 1 is probably the best.  Unit testing is about test cases.  Production code is abstract, because it’s supposed to implement a single abstract contract for an effectively infinite domain of inputs.  What unit tests do is to select a meaningful, representative set of sample inputs, where the expected output is known in advance.  Most good unit tests specify that expected output precisely; that is to say, the output is “hard coded”.

Some suites of unit tests might have a mix of abstractions and concrete cases.  Sometimes, expressing expected outputs concretely can actually be much more complex than making abstract assertions, and is not worth the effort.  But we shouldn’t lose sight of the fact that when it comes to unit tests, hard coding is good, and abstraction is at best a mixed blessing.

(Note: if you missed the literary reference from the title, see https://en.wikipedia.org/wiki/Considered_harmful)

Appearance and Reality

Section 11.8 of "Consciousness Explained" is a Platonic dialogue between Daniel Dennett and his reluctant (and fictional) student, Otto.  Here is an excerpt from the dialogue:

Dennett: These additions are perfectly real, but they are just more “text” -- there is nothing more to phenomenology than that.

Otto: But there seems to be!

Dennett: Exactly!  There seems to be phenomenology.  That’s a fact that the heterophenomenologist enthusiastically concedes.  But it does not follow from this undeniable, universally attested fact that there really is phenomenology.

(Page 366)

It sounds very reasonable, doesn’t it?  “There seems to be phenomenology” doesn’t imply “there is phenomenology.”  Appearance does not imply reality.

The problem is with Dennett’s unorthodox theory of appearances, which he gives a few pages earlier in the same dialogue.

Now you’ve done it.  You’ve fallen into a trap, along with a lot of others.  You seem to think there’s a difference between thinking (judging, deciding, being of the heartfelt opinion that) something seems pink to you and something really seeming pink to you.  But there is no difference.  There is no such phenomenon as really seeming -- over and above the phenomenon of judging in one way or another that something is the case.

(Page 364)

Dennett seems to be saying that (for some proposition P) “P appears to be true” is equivalent to “I believe that P is true”.  If that is the definition of seeming, then “P seems to be true but it is actually false”, is equivalent to “I believe that P is true but it is actually false”, which makes no sense.

Rotating Images

In Sweet Dreams (sorry I’m not giving page numbers in this essay -- Kindle isn’t showing me page numbers) Daniel Dennett argues that practicing experimental psychologists work under the assumptions of heterophenomenology, and not classical phenomenology (which Dennett sometimes calls “autophenomenology”.)  He cites as an example experiments by Roger Shepard where subjects are shown drawings of two three-dimensional shapes and asked if they are actually the same shape in two different positions.  Apparently, the subjects got the correct answer a lot of the time.  Dennett writes:

Most subjects claimed to solve the problem by rotating one of the two figures in their “mind’s eye” or imagination, to see if it could be imposed on the other.

Shepard argued that the subjects actually did solve the problem by rotating the shapes in their imagination, and he supported this claim by trying to show that the time it took to solve the problem correlated well with the “rotation distance” between the two shapes, that is, how many degrees the shape would need to be rotated from the position of the first shape to the position of the second shape.  “This didn’t settle the issue,” Dennett writes, “since Pylyshyn and others were quick to compose alternative hypotheses.”

Pylyshyn, Dennett argues, is clearly practicing heterophenomenology.  The subjects claim to be rotating mental images -- they report a conscious experience -- and Pylyshyn’s hypotheses suggest that no such experience actually happens.  Even Shepard seems to be practicing heterophenomenology.  If he simply assumes that his subjects actually experience what they think they are experiencing, there would be no reason to find further evidence of those experiences.

Dennett writes:

Subjects always say they are rotating their mental images, so if agnosticism were not the tacit order of the day, Shepard and Kosslyn would never have needed to do their experiments to support subjects’ claims that what they were doing (at least if described metaphorically) really was a process of image manipulation.

This doesn’t quite follow, IMAO.  Dennett doesn’t seem to consider the possibility that there is no “order of the day”, that some experimental psychologists identify with heterophenomenolgy and some identify with classical phenomenology.

Furthermore, I don’t think that Pylyshyn’s alternative hypotheses are actually relevant to heterphenomenology.  Dennett assumes that if the alternative hypotheses were true, it would imply that the subjects’ reports were false, but IMAO this doesn’t follow.  It’s possible that the brain subconsciously solved the problem through some non-rotational algorithm, but people still imagined the images rotating -- the experience may have reflected the nature of the problem being solved, rather than the process of the problem being solved.

In general, these image rotation experiments are not phenomenology experiments at all -- their relevance to phenomenology is indirect.  The experiments analyze the brain’s computational competence, rather than the person’s conscious experiences.