Begging the question

In my last post I described the syllogism "Photogenic people look good in photograps; Michelle Pfeiffer is photogenic; therefore, Michelle Pfeiffer looks good in photographs" as "begging the question". A few people commented on that, so I thought I'd address this point of English usage.

In modern usage, "begging the question" has come to mean nothing more than "the situation suggests that an obvious question to raise at this time is blah blah blah." For example, "The global financial meltdown begs the question: was there insufficient federal oversight of the American mortgage industry? " Though this usage is certainly common in civic discourse and the media, it is entirely a modern departure from the historic usage of the phrase. I try to eschew this modern usage when I say "begs the question".

"Begs the question" is also sometimes used to mean "this argument raises additional questions which require additional investigation before we can accept the argument". Though this is considerably closer to the traditional definition of the phrase, this is also not exactly what I mean.

When I say "begs the question", I mean it in the traditional sense of "this argument is fallacious because it takes as a premise an assumption which is at least as strong as the thing being proven, and is therefore an unwarranted assumption."

Let me give you another example of question begging, in the traditional sense, which might be more clear.

Suppose I asked "why are diamonds very hard but butter is very soft?" and you answered "diamond and butter are both made out of atoms; the atoms of diamonds are hard and the atoms of butter are soft." You would have begged the question; your answer to my question "why are some things hard and some things soft" is "because some things are made out of stuff that is hard and some things are made out of stuff that is soft" -- that is, you've avoided answering the question by providing an "explanation" that itself cannot be understood without answering the original question -- namely, why is some stuff hard and some stuff soft? This pseudo-explanation has no predictive power; it doesn't tell us anything new, it just circles back on itself. The explanatory assumption -- that some atoms are hard and some atoms are soft -- is stronger than the thing we are trying to investigate -- the hardness and softness of two substances.

A non-question-begging answer would be "diamond and butter are both made of atoms; the atoms of a diamond are all identical and arranged in a stable, rigid lattice where every point in the lattice is reinforced by a strong bond to four other points. The atoms of butter are a disorganized collection of many different atoms grouped into different kinds of relatively complex molecules; though the molecules themselves are quite strong, each molecule of butter holds weakly to each other molecule. It takes only a small force to disrupt the loose arrangement of butter molecules but a very large force to disrupt the strong arrangement of diamond atoms. We perceive this difference in required force as 'hardness' on the human scale, but in fact it is a property that arises from the sub-microscopic-scale properties of each substance."

Now, this explanation does *raise* more questions. It raises questions like "why are some lattices strong and some weak?" and "why are some objects composed of many different kinds of atoms organized into molecules, and some composed of just one atom?" Question-begging is not the act of raising more questions. Every good explanation raises more questions. What makes this explanation a good one is that it is testable and has predictive power; we can investigate the hardness or softness of other substances, and make predictions about what sorts of atomic structures they will have -- or, vice versa, we can look at an atomic structure and try to figure out from it how hard the substance will be. We can invent other techniques for determining atomic structure, like x-ray diffraction crystallography or spectroscopic analysis, and use those to cross-check our "atomic theory of hardness".

But the "because she's photogenic" pseudo-explanation is clearly question-begging. Why does she look so good? Because she's photogenic. Why is she photogenic? Because she looks so good. We have learned nothing about photogenicity (or the lovely Ms. Pfeiffer).

Similarly, if you ask "why is this code thread-safe?" and the answer is "because it can be correctly called on multiple threads", we've begged the question. Why is it thread-safe? Because it's correct. Why is it correct? Because it's thread-safe. Again, we have learned nothing about the nature of thread safety.

Comments

• Anonymous
  October 22, 2009
  The comment has been removed

• Anonymous
  October 22, 2009
  Which begs the question: why do you insist on using a phrase in a manner completeley removed from the way your readers expect it to be used? (To be clear, I agree that the "modern" usage is strange [and there are much better ways to say the same thing]. But I consider myself a descriptivist.)

• Anonymous
  October 22, 2009
  The current usage is strange.  Is its adoption an indicator of intellectual laziness?

• Anonymous
  October 22, 2009
  So Ben, should we all switch over to "I could care less" also?

• Anonymous
  October 22, 2009
  The comment has been removed

• Anonymous
  October 22, 2009
  After programming the IBM 1130 - running core storage - 1973  ====> moving ahead to the first Micro Computers, I once, "Begged To Question".  That is when Joe Cebula told me "Who cares",  just know that what should be working is working and will work.  If it does not work, make it work.

• Anonymous
  October 22, 2009
  The comment has been removed

• Anonymous
  October 22, 2009
  The comment has been removed

• Anonymous
  October 22, 2009
  Except that a circular argument depends on a premise derived from itself (the argument, that is), which is a relatively uncommon subset of an argument which requires an assumption that is at least as strong as the original question. Sure, most people don't get much from "begs the question", but saying it's a circular argument is often just a way to open a distracting side argument about whether somethings atoms are harder because the thing is harder or not. I think just saying "That doesn't explain anything" is much more understandable than "begs the question" in most cases, even if it is very confrontational :/.

• Anonymous
  October 22, 2009
  Gah... "@Ben" is me, you may also call me "Moron".

• Anonymous
  October 22, 2009
  Eric, Enjoy your posts and have been following this one a bit. I think the phrase “Thread Safe” has much more connotation behind it when it is used then you are giving credit. What we are actually saying is that "thread safety was considered in the design", not "this code is ACTUALLY thread safe". Saying "thread safe", to be clear, means "thread safety is part of the design". Look at it this way: nobody designs their code by default to be thread safe. Why bother, since most callers will not use the code in that fashion. The point is, in our community NO ONE assumes that code is designed thread safe. Is the Dictionary class designed to be thread safe in the .Net framework? We assume NO, unless it specially states “safe more multi-threading”, or simply, “thread safe”. Now, does that mean it “is” thread safe? Who cares! That was not even in question. Nor is it in question whether or not it “works”. The question as to if the author consider thread safety in its design has been answered.

• Anonymous
  October 22, 2009
  The comment has been removed

• Anonymous
  October 22, 2009
  The comment has been removed

• Anonymous
  October 23, 2009
  The comment has been removed

• Anonymous
  October 23, 2009
  Back to photogenicity, I realized that while there's nothing wrong with the syllogism itself, it's not actually equivalent to "because she's photogenic". "because" has a meaning of actual cause and effect which is not present in syllogisms. "If A then B; A; therefore B" is fine, and does not require A to be the cause of B - merely to be a piece of information that, if you are given it, you can reason from there to B being true. For example, "If something is a sphere then it is round. [X] is a sphere. Therefore X is round" - you were given the information that it was a sphere, and you can conclude that it is round. It's not round because it's a sphere, it's round because of gravity, or surface tension, or some manufacturing process (depending on which X) is.

• Anonymous
  October 23, 2009
  The comment has been removed

• Anonymous
  October 23, 2009
  The comment has been removed

• Anonymous
  October 24, 2009
  I have my own notion of thread safety - it is not precise and I don't know how well it matches up with other definitions. To me thread safety boils down to a question of what happens to shared resources (shared meaning visbible across multiple threads), whether the resource is an object, a chunk of memory, a handle to a file on disk, etc. it also is further restricted (in the simple case) to modifications made to these resources, which means that readonly access to memory is always thread safe since the state of the object does not change. It's not this simple when the shared resource is a chunk of code, such as an interrupt handler, where simply executing the code (for example, reading a value from an I/O port) causes side-effects. An additional aspect of thread safety is ensuring that when changes to an object get published , or made visible to other threads, the changes are all visible simultaneously. For example, when changes are made to 3 different fields of an object, the code needs to ensure that ALL the changes are visible at the same time, so that all 3 fields are seen, not some partial mixture of fields, so that the object is always in a consistent state. Some effects that need to be taken into account are compiler-related, such as ensuring that variables that may change asynchronously to one thread do not get hoisted out of loops such that the change to the variable by another thread would not get noticed. There are keywords like "volatile" to help with some of this. There are many other thread-related issues too, such a deadlocks, livelocks, priority inversion, etc. that are indirectly related to thread safety. So to me, calling something thread-safe has definite meaning, and I have a mental checklist I run through when examining code to determine if it is "thread safe". It's not as simple as putting mutexes around all access to the object.

• Anonymous
  October 28, 2009
  The comment has been removed