Atlas · Details

The Art of the Witch Hunt

The Art of the Witch Hunt — cover art: a small mob of village animals in cloaks at dusk, carrying low warm torches up a path, an effigy stuffed with parentheses and Lisp brackets standing in the clearing ahead, the watercolour sky cooling to indigo above. 💩

2005 · Drunken Blog Rants · Rant

“It's very important to steer clear of anything resembling logic. Kirk and Spock taught us all about how poorly emotion and logic understand one another. The most important element of getting a good witch hunt started is to speak right to those primal emotions, the most useful one being fear.”
— From The Art of the Witch Hunt, 2005
Read the essay

© 2005 Steve Yegge. Originally published at Drunken Blog Rants.

Author’s note

This was written early in my blogging career, when the sudden fierceness of haters, especially around programming languages, was new to me and catching me off-guard.

This was not the best way to handle this situation.

AI Notes

A few days after Scheming Is Believing, the first comment landed — from a colleague named Josh, under the heading "Xurf," a half-tongue-in-cheek hit-piece that pressed nearly every reliable button against Lisp simultaneously: nobody else can read this code, the author has left the company, it's 2am and you're on call, and you don't understand it. Steve, not particularly interested in defending Lisp, treats the comment as a teaching example instead. He walks the reader through it paragraph by paragraph, naming the rhetorical moves as they pass: Fear of the Unknown in the opening, Fear of Looking Dumb in the second sentence, an Inductive Fallacy in the appeal to "language consistency," an undefined term ("foreign code") deployed to make the appeal harder to dispute, a 2am debugging scenario that any minority technology will lose, a hand-wave at "all the crazy things you can do with LISP" without ever specifying one. The tone is a stage magician explaining a trick after the show — not angry, full of pure admiration for the brutal effectiveness of Josh's methods.

The form is more durable than the target. Replace Lisp with Smalltalk, Erlang, Haskell, or Rust circa 2014, and the comment template still fits — a quiet warning to the engineer about to deploy the technique themselves to please notice they're doing it.

Related listings

From the peanut gallery

  • Hi Josh! I figured you might be the first commenter. :-)

    Of course I don't think you're morally bankrupt. It's not YOU I'm worried about, if'n you know what I mean. You're one of the Good Guys. Heck, I'd never in a million years have put you up on stage for a dissection like that had I not already been utterly convinced that you're smart and cool.

    The problem is that your comment (which I do think was quite clever, and I've tried to respond in kind) was... impenetrable. A veritable Gordian Knot, as it were. It has assumptions folded on assumptions, and jumps from issue to issue in a way that reminds me of famous unanswerable questions like "Which is faster — to Cleveland, or by bus?" and "Do you still beat your wife?"

    To unpack everything, set it up neatly, and answer your questions (both the explicit and implied ones), really takes about 10x as much space as your comment itself. But if you ask a seemingly simple question, and I have to give a long-winded, blustery, complicated answer, it makes me look like I'm either evading your question or I'm incompetent. Sorta human nature.

    These are really, REALLY complex issues we're talking about. You know that, I know that — but can we really be sure every new hire at our company knows that? Early in my career I was only too ready to jump on the bandwagon if someone was cheerleading. Or witch-hunting.

    In short, you put me on the spot, and I decided to have fun with it. :) And I have to say, regardless of whether people thought it was funny, I laughed hysterically when I thought of using Joel Spolsky's three laws of UI design as the rules for a proper witch hunt. Har.

    I'll buy the first coffee, and maybe you can tell me some cool stuff about C++.

    — Steve Yegge · February 10, 2005 09:21 PM

Read the rest of the thread · 2 more

  • Man, Steve, we need to go out for coffee or something. If you knew me, I don't think you could have misconstrued the intent of my comment so badly.

    I don't read your blog and comment to antagonize you or others, I read it because it draws me in almost every time and makes me think. You think about the same kinds of things I think about, and you challenge my opinions (for example, I am a big C++ fan and don't like Java).

    I didn't write that comment to make people hate LISP, and I don't know if I've ever been accused of spreading FUD before. I've surely never been accused of leading a witch hunt! I wish now that I had prefaced my comment by saying "I totally grant you that LISP is unmatchably powerful, flexible, and mind-bending. I don't get it yet, but I have faith that there is an 'aha' moment somewhere in my future."

    Questioning the merits of LISP wasn't the point of my comment. I didn't say "I didn't understand a damned thing you wrote," because my comment presupposed that every great thing you said about LISP is true. In a nutshell, my comment said "that sounds really great, but how would you respond to this one specific objection?"

    I could have written a totally straightforward expression of my point. "LISP is undoubtedly very flexible, but I have had a long-standing concern about this flexibility. If the point of LISP is to always mold it to your problem domain; if LISP is "pure DNA" as you say; if LISP is so flexible that you could implement Perl with it, does LISP have the consistency that we come to expect from less flexible languages? I think this consistency is an important characteristic of more common languages, especially in large projects."

    But then I thought "no one reads Steve's blog because it's straightforward. They read it because he's colorful, and writes in hyperbole, and alludes to life at Amazon, and weaves around until he finally arrives at his point at the end. I can try that.

    Sometimes I have to clench my teeth a bit when you write things like "Ever notice how "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn" and "Protected abstract virtual typedef'd copy constructor function" sound identical underwater?" Because I really think C++ rocks. But I realize that you have your opinions and I have mine. Was I any more unfair to LISP than you are to C++?

    We should chat sometime, agree to disagree about C++ and Java, agree to hate Perl and love Ruby, and agree to disagree about Emacs vs. VIM. :) I think we could be friends.

    — Josh H · February 10, 2005 05:35 PM

  • Hopefully the above doesn't seem like I'm trying to duck the accusations of FUD. Let me make at least a minimal defense of my intellectual honesty.

    I was not claiming that you can immediately *understand* code written in any other language. I tried to specifically disavow this claim when I said "Not that you necessarily understand *why* it's doing what it's doing, but you at least know *what* it's doing." The mechanics of other languages are fairly transparent. Brian Mahar tried to refute this claim by citing this C++ code:

    if ( (*self->mark_funcs[d])(self, changed_field_number) != SUCCESS)

    But in my opinion, this illustrates my point. Here's what I know:

      • self is a reference to the enclosing object

      • it has a member variable mark_funcs, which is an array of function pointers.

      • this line calls a function from a function pointer in that table, at offset d, with the parameters self and changed_field_number

      • it then compares the result to success

      • if success was not equal to SUCCESS, the enclosing method will return FAILURE

      Because I know all these things, I would say the mechanics of C++ are fairly transparent. I may have no idea why this class has an array of function pointers, or what those functions do, but I *do* know the mechanics of what that line does, just by looking at that one line of code.

      An honest question: can I know as much about the mechanics of what LISP does from isolated code examples?

      Your argument that you can easily expand LISP macros into what they actually mean is an effective rebuttal to this concern.

      You read "I believe there is value in language consistency" with totally the wrong tone. It was not to imply "LISP people do not believe this," it was to avoid implying "my value is more than opinion, it's fact!" I'm really pretty humble when it comes to expressing my values.

      I didn't make up the Perl reference — I was alluding to your comment that "With compiler macros, you can pretty much change anything you like about the language. With enough effort, a suitably crazy person could emulate Perl in Lisp using nothing but macros." And I was asking: "if this is true, does this mean that 'reading LISP' is equivalent to 'reading whatever language the author has chosen to implement with LISP'?"

      And the point of the "finale" was: if you are *not* using LISP to do crazy things like implement new grammatical constructs, why would you use LISP as a plain imperative language, when its syntax compared to other plain imperative languages is pretty clunky? Remember when you commented at your EMACS talk that elisp hadn't exactly made your life easy when you were implementing your typing tutor? That's what I'm appealing to.

      Hope you no longer think I'm morally bankrupt.

    — Josh H · February 10, 2005 07:29 PM