The other day, I was wondering why Clojure fits my brain so well. I think I was relaxing on my old couch, drinking cheap beer, eating a gas station pastry, and drawing doodles on a stack of overdue bills I forgot to pay. Little did I realize, these things are all connected.
I have a hypothesis that people choose programming languages based on their personality. For the purposes of this write-up, I’ll use the well-known distinction between type A and type B people. This may be pop psychology stuff, but it’s convenient for my point so in the spirit of American politics I will treat it as fact.
Type A people are very organized, competitive, punctual, and like to plan ahead. When I was a kid, these were the ones who had perfect grades, competed in track or swimming, and on top of that they were nice people so I couldn't even hate the fuckers. Type B people, on the other hand, are laid back and like to do things spontaneously. Like The Dude from The Big Lebowski, they are comfortable with unknowns and rely on serendipity to guide them.
Here's the hypothesis: As programmers, type A people gravitate towards languages that are stricter and require more up-front work to get code to run. This includes static typing and compiler-enforced style rules. In contrast, type B people prefer languages that enforce very little at compile-time. They place more value on the ability to change a live program with a REPL, so they can make quick, spontaneous changes with little pre-planning.
Type A people prefer a "top down" methodology, modeling everything in types and planning out the architecture before any functionality is implemented. You see this in the "API first" approach in object-oriented languages like Java. You also see it in ML family languages like Haskell, where you are often advised to follow type-driven development (writing type signatures before implementing anything).
Type B people prefer a "bottom up" methodology, immediately implementing functionality and interactively building on previous work until a larger structure emerges organically. You see this in the Lisp community, where REPL-driven development is the norm. The notion of starting from the bottom is also reflected in the prose of a well-known Canadian rapper who claims to come from humble beginnings.
As a fan of both basketball and pointless sidetracking, I'll take a moment to bring up my favorite example of this psychological dichotomy. Kobe epitomizes the type A persona. He was obsessively competitive and had an inhuman work ethic. There is no doubt in my mind that Kobe wouldn't even begin building a Twitter clone until he had it all mapped out in diagrams and type signatures, and had all contributors sign a blood pact that their first born would be sacrificed if they violated whitespace conventions.
Shaq was an entirely different beast. His laziness is perhaps equally legendary, and is one of the reasons he feuded with his teammate. It's been said that Shaq played basketball to do all the things he really wanted to do: making terrible movies, rapping about Kobe eating his ass, and holding things. Shaq's Twitter clone would be running directly out of his own personal REPL session, projected next to his indoor pool so he could hack on production code by shining a laser pointer from his floating lounge chair.
A top-down approach seems ideal for well-understood problems where correctness is the most important attribute. If you're making accounting software, or the avionics software for a plane, you're not necessarily blazing any trails. You have a list of requirements, and you need to satisfy them with minimal defects -- especially if money and lives are on the line.
A bottom-up approach works well for projects with a lot of unknowns, like artificial intelligence or anything artistic. Paul Simon didn't come up with The Sound of Silence from a list of requirements. He sat in his bathroom with the lights off and riffed on his guitar until genius poured out. It's no accident that there are Clojure projects like Overtone and Quil. A REPL session is the programmer's guitar riff.
Your personality is a deep-seated and, yes, personal thing. When you are confronted with someone with an opposite personality, it's not uncommon to feel a visceral reaction. When a type A programmer looks at a type B programmer's code, they see an unmaintainable mess. When the reverse happens, they see an over-architected nightmare. Both may very well be right.
Clojure author Rich Hickey is an obvious example of a type B programmer. He's a brilliant language designer and public speaker, but he has coding habits that drive type A people batty. Clojure's code has a notoriously weird Java indentation style, he often commits his personal IntelliJ files, and it isn't hard to find his commented REPL scratch pad in random places. He also looks a bit like The Dude.
When looking at languages through this lens, it becomes obvious that a lot of internet flamewars are predicated not on objective disagreements, but subjective personality differences. It explains why some people use a language like Clojure and are immediately smitten, while others have an allergic reaction.
The correct -- though pathetically diplomatic -- take-away from this is that both sides are right. The type A programmers are right that correctness and uniformity is important for building robust, maintainable software. The type B programmers are right that a tight feedback loop and experimentation is important for building simple, innovative software.
Maybe some day we will figure out how to get the benefits of both. If you think we already have, and that your favorite language provides the answer, you probably haven't thought hard enough about the problem. Beneath that cold, rational shell, you are a warm-blooded mammal with a unique emotional tapestry that reveals itself in every line of code you write.