Advocacy
Five years ago, Mark-Jason Dominus wrote a piece called Why I Hate Advocacy, objecting to people who tout one programming language over another on essentially religious grounds.
(This is especially amusing because Dominus was the creator of a fun (but now-defunct) game called Advocacy lo these many years ago, in which (I oversimplify here) players attempted to come up with rationales to justify terrible ideas.)
Anyway, the essay is a good piece about programming languages, but I'm linking to it because it's also a good piece about advocating anything else to the point of no longer being able to rationally weigh its pros and cons. If you find yourself clinging to, say, a political organization, or a genre, or a computer operating system, believing any criticism of the item in question to be a personal affront against you, you might find this an interesting read.
And you don't have to know much about computers to follow most of it; in fact, the essay starts by talking about baseball. It does refer to specifics of various languages, but you can get the general idea without understanding those bits; all you really need to know is that Perl, Standard ML, Pascal, C, PHP, and Fortran are all programming languages of various sorts. You can skim the part about linked lists and such; just be sure to read the section titled "Drink the Kool-Aid." It starts out:
I think the root of the problem is that we tend to organize ourselves into tribes. Then people in the tribe are our friends, and people outside are our enemies.
(Edited to add: Also perhaps relevant is Barack Obama on political advocacy and alienating people.)
. . . I'm obliquely reminded of something that came up back when I worked at SGI, in the early '90s. The company had developed two different kinds of software tools for programmers who wanted to create 3D graphics, products named "Inventor" and "Performer." In very general terms, I thought of Inventor as primarily oriented toward creating and manipulating 3D models of objects, while Performer was primarily designed for quickly drawing immersive simulated environments that you could move through in realtime.
But the two teams were rivals, both led by charismatic and strong-willed managers (both of whom I liked, I should note), and there was a sense that anything that benefited one team hurt the other. I was one of several writers who at various times attempted to write up an explanation for our customers of which tool was best for which kinds of work, because from the customer's point of view it was hard to tell which one to pick for a given task.
But every attempt to suggest that a given task was best served with one or the other of the two tools met with resistance from the teams. I eventually concluded that the only way to satisfy both teams was to tell customers that both products were the best possible tool for every task.