Boyer has made some of the deepest insights into the psychology of property (Boyer, Reference Boyer, Laurence and Margolis2015, Reference Boyer2018). The target article probably adds to these insights if someone can decipher the scrolls of cryptic notation, such as P() tags, Min(A), and Brep[Xrep[Min(A)]].
The article goes wrong with the notation introduced in Table 2. On its face, we should be skeptical that speaking in code will help us understand property. Throughout academia, scholars are mesmerized by secret codes, encrypted texts, and appearances of technicality. So we need to ask whether an artificial code is actually useful or yet another indulgence in scholarly solipsism.
On this point, the author provides little justification: a single sentence which claims that the notation helps by “avoiding the ambiguities of natural language glosses” (target article, sect. 5.2). The claim echoes a common refrain among modelers and jargon peddlers of many persuasions. Natural language is too ambiguous, they say, and arbitrary terms like Min(A) and Brep[] make ideas clearer. But this claim is dubious.
Cognitive scientists know that natural language is an evolutionary marvel of expressive power. Yes, language can be ambiguous; so can reality itself. But arbitrary code is far more ambiguous than language. Its meaning is hidden in the author's mind, it lacks the advantages of words and grammar, and it is untested by the demands of daily use. Besides, the author's notation does not escape natural language. Instead, readers must memorize a table of definitions in language, and then mentally substitute words for notation while reading, adding ambiguity in translation.
Consider the advice of professional programmers, whose computational programs need to actually run, and who therefore put the greatest premium on precision and clarity. Programmers constantly complain that they cannot understand each other's code, due to the bad habit of arbitrary notation. The best programmers tell us the remedy is natural language. For instance, the prominent guide Clean Code advises programmers to use informative names for variables and functions (Martin, Reference Martin2009). In chapter 2, “Meaningful names,” Martin advises programmers to replace ambiguous variables like “d” with names like “daysSinceCreation,” and to replace general labels like “theList” with specifics like “gameBoard” (p. 18). Google and Microsoft agree (Fig. 1). More particularly, the book recommends noun phrases for classes and objects, such as “Customer” and “addressParser,” and verb phrases for functions and methods, such as “deletePage” and “postPayment” (p. 25).
In fact, Martin (Reference Martin2009) applies evolutionary psychology to make the case. The section, “Use pronounceable names,” explains:
Humans are good at words. A significant part of our brains is dedicated to the concept of words. And words are, by definition, pronounceable. It would be a shame not to take advantage of that huge portion of our brains that has evolved to deal with spoken language. So make your names pronounceable. (pp. 21–22)
Continuing, Martin explains that arbitrary strings are difficult to discuss.
If you can't pronounce it, you can't discuss it without sounding like an idiot. “Well, over here on the bee cee arr three cee enn tee we have a pee ess zee kyew int, see?” This matters because programming is a social activity. (p. 22)
Indeed, cognitive science is also a social activity, requiring a fluent vocabulary. We cannot fully debate a theory while tongue-tied in twisters like, “how do pee parentheses tags relate to bee rep open bracket min parentheses ay close bracket?”
Just as the programmers warned, Boyer's arbitrary code spawns confusion. First, what is a P() tag? Does the “P” allude to “property,” “possession,” or something else? Is a P() tag the same as a P() representation, P() relation, or P-intuition, and are P-cues the same as P-indices? If so, synonyms multiply the ambiguous jargon. The author seems to prefix “P-” to any word, blurring technical terms with ordinary words bearing an arbitrary prefix. I cannot tell whether the model of P() in Figure 1 makes specific claims because the inputs and outputs are open-ended.
Second, what is Min(A)? If it means that A would cooperate with someone, then we have adjectives like cooperative, friendly, and nice, which has served as a technical term for cooperative strategies (Axelrod, Reference Axelrod1984). Nearby, “Brep[]” seems to mean that B believes something, which can be expressed with verbs like think or believe. “Brep[Min(A)]” in natural language means “B thinks A is friendly.” Overall, I cannot tell whether the code introduces new ideas about cooperation or expresses familiar ideas in Min(A) and Brep[].
Third, what is an L() tag? What does the “L” allude to? L() combines the previous elements, compounding the confusion. The discussion enumerates lists of familiar ideas expressed in code and tortuous language. For instance, “A is in a P() relation with thing t” (target article, sect. 7.2.2) is not more precise but merely a circumlocution for “someone owns something” or “someone has something,” convoluted by the extraneous concepts of be, in, relation, and with.
The main point of L() seems to be that people weigh the value of a cooperative partner when deciding whether to respect or defend that person's property. What is notable about this claim? Later, the author argues that thieves do not infer their victims' ownership (target article, sect. 8.2.1). But then the thief would not hide their thievery. A skilled thief needs the ability to judge ownership impartially to anticipate the moves of owners and observers.
Boyer acknowledges these terms are meaningless and argues that saying what they mean “would be misguided and misleading” because they refer to “mappings of inputs to outputs” (11.1). This amounts to saying, “I have a theory but it would be misleading to tell you what it is.” That sort of theory is incomprehensible and thus unfalsifiable. Again, the author's justification assumes that meaningless code is less ambiguous than language and does not require translation to language to be understood. This assumption does not hold for real programs that map inputs to outputs, nor for theoretical programs in the mind.
You have
Access
Boyer has made some of the deepest insights into the psychology of property (Boyer, Reference Boyer, Laurence and Margolis2015, Reference Boyer2018). The target article probably adds to these insights if someone can decipher the scrolls of cryptic notation, such as P() tags, Min(A), and Brep[Xrep[Min(A)]].
The article goes wrong with the notation introduced in Table 2. On its face, we should be skeptical that speaking in code will help us understand property. Throughout academia, scholars are mesmerized by secret codes, encrypted texts, and appearances of technicality. So we need to ask whether an artificial code is actually useful or yet another indulgence in scholarly solipsism.
On this point, the author provides little justification: a single sentence which claims that the notation helps by “avoiding the ambiguities of natural language glosses” (target article, sect. 5.2). The claim echoes a common refrain among modelers and jargon peddlers of many persuasions. Natural language is too ambiguous, they say, and arbitrary terms like Min(A) and Brep[] make ideas clearer. But this claim is dubious.
Cognitive scientists know that natural language is an evolutionary marvel of expressive power. Yes, language can be ambiguous; so can reality itself. But arbitrary code is far more ambiguous than language. Its meaning is hidden in the author's mind, it lacks the advantages of words and grammar, and it is untested by the demands of daily use. Besides, the author's notation does not escape natural language. Instead, readers must memorize a table of definitions in language, and then mentally substitute words for notation while reading, adding ambiguity in translation.
Consider the advice of professional programmers, whose computational programs need to actually run, and who therefore put the greatest premium on precision and clarity. Programmers constantly complain that they cannot understand each other's code, due to the bad habit of arbitrary notation. The best programmers tell us the remedy is natural language. For instance, the prominent guide Clean Code advises programmers to use informative names for variables and functions (Martin, Reference Martin2009). In chapter 2, “Meaningful names,” Martin advises programmers to replace ambiguous variables like “d” with names like “daysSinceCreation,” and to replace general labels like “theList” with specifics like “gameBoard” (p. 18). Google and Microsoft agree (Fig. 1). More particularly, the book recommends noun phrases for classes and objects, such as “Customer” and “addressParser,” and verb phrases for functions and methods, such as “deletePage” and “postPayment” (p. 25).
Figure 1. Rules for naming from Google's Style Guide, left, and Microsoft's Naming Guidelines, right (https://google.github.io/styleguide/jsguide.html#naming, https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions).
In fact, Martin (Reference Martin2009) applies evolutionary psychology to make the case. The section, “Use pronounceable names,” explains:
Humans are good at words. A significant part of our brains is dedicated to the concept of words. And words are, by definition, pronounceable. It would be a shame not to take advantage of that huge portion of our brains that has evolved to deal with spoken language. So make your names pronounceable. (pp. 21–22)
Continuing, Martin explains that arbitrary strings are difficult to discuss.
If you can't pronounce it, you can't discuss it without sounding like an idiot. “Well, over here on the bee cee arr three cee enn tee we have a pee ess zee kyew int, see?” This matters because programming is a social activity. (p. 22)
Indeed, cognitive science is also a social activity, requiring a fluent vocabulary. We cannot fully debate a theory while tongue-tied in twisters like, “how do pee parentheses tags relate to bee rep open bracket min parentheses ay close bracket?”
Just as the programmers warned, Boyer's arbitrary code spawns confusion. First, what is a P() tag? Does the “P” allude to “property,” “possession,” or something else? Is a P() tag the same as a P() representation, P() relation, or P-intuition, and are P-cues the same as P-indices? If so, synonyms multiply the ambiguous jargon. The author seems to prefix “P-” to any word, blurring technical terms with ordinary words bearing an arbitrary prefix. I cannot tell whether the model of P() in Figure 1 makes specific claims because the inputs and outputs are open-ended.
Second, what is Min(A)? If it means that A would cooperate with someone, then we have adjectives like cooperative, friendly, and nice, which has served as a technical term for cooperative strategies (Axelrod, Reference Axelrod1984). Nearby, “Brep[]” seems to mean that B believes something, which can be expressed with verbs like think or believe. “Brep[Min(A)]” in natural language means “B thinks A is friendly.” Overall, I cannot tell whether the code introduces new ideas about cooperation or expresses familiar ideas in Min(A) and Brep[].
Third, what is an L() tag? What does the “L” allude to? L() combines the previous elements, compounding the confusion. The discussion enumerates lists of familiar ideas expressed in code and tortuous language. For instance, “A is in a P() relation with thing t” (target article, sect. 7.2.2) is not more precise but merely a circumlocution for “someone owns something” or “someone has something,” convoluted by the extraneous concepts of be, in, relation, and with.
The main point of L() seems to be that people weigh the value of a cooperative partner when deciding whether to respect or defend that person's property. What is notable about this claim? Later, the author argues that thieves do not infer their victims' ownership (target article, sect. 8.2.1). But then the thief would not hide their thievery. A skilled thief needs the ability to judge ownership impartially to anticipate the moves of owners and observers.
Boyer acknowledges these terms are meaningless and argues that saying what they mean “would be misguided and misleading” because they refer to “mappings of inputs to outputs” (11.1). This amounts to saying, “I have a theory but it would be misleading to tell you what it is.” That sort of theory is incomprehensible and thus unfalsifiable. Again, the author's justification assumes that meaningless code is less ambiguous than language and does not require translation to language to be understood. This assumption does not hold for real programs that map inputs to outputs, nor for theoretical programs in the mind.
Financial support
This research received no specific grant from any funding agency, commercial, or not-for-profit sectors.
Competing interest
None.