I think we’ve all been straw-manned at one point or another.
For those unfamiliar with the term, a straw man is basically a false representation of an opposing opinion, which one attacks in order to present the illusion of having defeated said opponent in an argument. I remember one of my philosophy professors in college explained the concept using the example of a political debate where one candidate is unable to attend and so a straw man is brought in as a substitute. This allows the candidate in attendance to make unfair or flat-out inaccurate characterizations of his opponent’s platform: “My opponent likes to pretend that…”, “My opponent would have you believe that…”, etc.
This is how the term straw man is generally understood and presented: as a mean-spirited, aggressive tactic for undermining another person’s viewpoint. But I think it’s actually not so different from the much more common, much less malevolent scenario where two people simply misunderstand each other.
Case in point: many moons ago, a user on Stack Overflow posed a seemingly harmless question asking users to list some confusingly-named methods in the .NET BCL—cases where, just by looking at a method, a developer might think it does one thing, when in fact it does another.
In other words, mislabeled stuff.
There were plenty of great answers, which prompted a lot of good discussion (e.g., what should you call such and such a method, etc.); however, there was also a pretty heated argument about one answer in particular: my answer.
I said that the
DateTime.Add method (and all the
DateTime methods whose names start with the word “Add”) has a misleading name. You know, because the
DateTime type is immutable, these methods actually return new values, yada yada yada.
DateTime d = DateTime.Now; d.AddHours(1.0); // This does nothing meaningful. d = d.AddHours(1.0); // THIS does something meaningful.
I suggested that the word “Add” implies mutability, primarily based on the precedent of such other methods as
List<T>.Add, and so on.
What I would have done is given these methods names starting with the word “Plus”:
DateTime.Plus, etc. I feel that this word doesn’t imply mutability, just as the phrase “x plus 5” does not imply any modification of the value stored at x.
To be clear: I realize this is 100% subjective. Someone else could see the word “Add” and not think it implies mutability, which undercuts the premise of my answer completely for that individual. I won’t dispute that.
But a funny thing happened with that answer: to my surprise, not only did some users disagree with me, they really disagreed with me. And it all started with a comment by a user who shall remain nameless (unless you click on the link above and look at the comments yourself, where you can clearly see his name):
I can’t say that I ever really thought twice about this.
DateTimeis a value type; it really doesn’t matter what its methods are called, none of them could possibly be mutators.
Never mind that this conflates the concepts of value types and immutability (don’t get me wrong; I believe the user in question has these concepts very straight in his head, but it is a misunderstanding shared by quite a few .NET developers); the real problem occurred a few comments later:
Consider if C# had date literals like VB and you could write
#5/14/2010#.AddDays(1). What would you expect this to do? I maintain that if people get this wrong, it’s their fault, not the Framework’s fault for having a “confusing” method name. If I say “take your date of birth and add 1 month”, that doesn’t imply that you should (or could) physically change the date on which you were born.
It’s about here in the discussion that a straw man started to enter the picture. Honestly I felt a bit like our exchange was beginning to look like this:
Me: Boy, that’s a misleading caption on that picture of an apple.
Him: Why? It’s obviously a Red Delicious.
Me: Yeah, but… the caption says Gala.
Him: So what? It’s deep red; the skin is shiny and smooth; it is in every way like a Red Delicious!
Me: If that’s really your argument, the caption could just as well say “Orange” and you would still think it’s not misleading.
Him: For it to say “Orange” would make no sense. What are you talking about?
Me: I know it wouldn’t; that’s my point: it’s a bad name.
Him: I’m sorry, but you’d have to be stupid to think that’s a Gala.
Me: I never said I thought it was a Gala. I said it was a misleading caption.
Now, I don’t believe this user had any particularly strong interest in arguing with me just for the sake of it (that would be kind of silly). Rather, this is what I think happened. When I said that the
DateTime.Add method (and its kin) had a confusing or misleading name, it reminded this particular user of other developers he’s interacted with, who may not understand the difference between value types and reference types, or why value types should generally be immutable, and thus why you should not call
DateTime.Add and expect the instance to be modified. And so as this user became increasingly agitated (or so it seemed to me), he was really arguing, not with me, but with those other developers of whom I reminded him simply by commenting on what I felt (and still feel) is a misleading name.
That is to say, the straw man in this case was perhaps not an imaginary figure, but in fact other people. And maybe the whole reason for the debate that ensued was not that the other user wanted to argue with me, but simply that the topic brought up associations in his mind, to which he had a strong negative reaction.
Or maybe I’m just wrong; I don’t know. But I still think those methods have misleading names.