Create a gist now

Instantly share code, notes, and snippets.

Clojure is for type B personalities

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 vs Type B

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.

Top Down vs Bottom Up

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.

Kobe vs Shaq

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.

Better for what?

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.

Culture Shock

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.

Stop the War

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.

jozip commented Jan 21, 2016

I like to say "make pottery with bricks is dumb, but so is building a skyscraper out of clay." Every tool and method has a purpose, and scarce few come out of pure stupidity or malice. It's depressing to see people forget this when they loudly proclaim their way the way of the righteous.


@oakes so how can a Type B programmer like you work (and keep working) on his own IDE for Rust, probably one of the Type A-est languages out there?


The clojure zipper code is super readable tho ^_^

oakes commented Jan 22, 2016

@ronjouch Rust was fun, and SolidOak was my way of learning it, but part of what motivated this write-up was the fact that I came crawling back to Clojure after my honeymoon with it =)

punkdit commented Jan 22, 2016

My characterisation of the two types would actually reverse the top-down/bottom-up labels: type-A's seem to be dithering around in the details, trying to assemble something larger, while type-B's get the big picture, but loose focus as they zoom in on the details.

In practice this explains the outward appearance: type-A's obsession with getting the plan right (because they are chronically lost), and type-B's rapid tinkering (because they never know if their crazy idea is going to work or not).


Personality types seems a bit broad of a stroke to to paint this with. I think it's as simple as short term memory. To work well with the lisp languages you need to have excellent short term memory: the ability to keep a tree visualized in your mind and to be able to jump around within that tree.


There are many truths I recognise here except one self-evident truth one just touched on above: that no one person is exclusively one type or the other. Any individual has to manage the tension between needing to work both bottom-up and top-down simultaneously or serially. Then collectively, a community has to manage a similar tension. Take the history of "rapid tinkering" that was Drupal up to Drupal 7 - as useful as that is - and then the feat of mapping that onto a framework that was intentionally designed (and evolved): Symfony 2 and PHP 7. Maybe Drupal 8 is not a cool enough example for you, but it's a real one and it has my respect. Anyway I think life is richer if we can enjoy the world from both the simultaneous perspectives of formal methods at one extreme and "rapid tinkering" at the other. Reminds me of the old adage: "If you think that programming is too hard, then parallel programming is three hard."


Perhaps another interesting facet of personality types in programming is Agile philosophies. Type B prefer a loose agility (small "a") at a higher level -- people over process, per the manifesto. Type A prefer an "Agile process", and this often leads to "team agreements" that include conventions on whitespacing. I would go as far as saying that how people practice "agility" is what separates the A's from the B's.

nilbot commented Jan 24, 2016

There are too much of cultural and personality strokes in this text where in reality most of these practices are not initially driven by preference, let alone by personality. And I find most of the categorization weird:

  • Find me a superstar C/C++ programmer who is not a bottom-up thinker.
  • The code formatting style as far as white spaces are concerned, are "forced" by diff, not hygene/religion.
  • bottom-up guys understand the big picture better than the top-down guys. example: unix
  • weakly typed features were first there because users know what they are doing, they need it to build things more quickly. dynamic typed feature were first there because again, users know what they are doing, they didn't need the feedback loop to see correctness, it's handy but they didn't need it. They needed the dynamic type to write shorter code to get the big picture quickly.

Obviously you can't compare tools meant for different jobs, but to start your reasoning with personalities is just way off.


Did you remove my previous comment?

oakes commented Jan 28, 2016

@andreaferretti I removed several comments. They were devolving into little ballads about static vs dynamic typing, which is only peripherally related to this write-up and more importantly bores me to death. I have no problem with disagreement if, as in @nilbot's comment, it's interesting and doesn't beat a dead horse.

fourth44 commented Feb 5, 2016

Bummer you removed precisely the two comments I wholeheartedly agree with.
I'm a B, love bottom-up quick-tinkering chaotic REPL-sessions and inferred static typing, correcting me where my mental image of the code dwells an astray path of unsoundness (without getting in my way).
I do agree very much with the importance of a creative, flexible approach to shaping software to best match the problem domain to be solved. Up-front design is rigid. Emerging abstractions are priceless. (especially with free compile-time proof 😉 )


I completely agree.
You helped me to understand that I'm a Type B person and that there is nothing wrong about it.
I'm from Philosophy and visual arts. I've got interested about the structure of programming languages because the process of my academic writing is in a bottom-up way and I thought I could find something about that in programming as an explanation. I don't know coding, but intuitively I started reading about Lisp because of its nested parens that are like an horizontal tree and the prefix notation that I see as thinking backward. Being a type B person as I am, is not weird that I'm also interested in the Processing language that is similar to Quil. Maybe there is also a relation with being left-handed.

peeb commented Feb 1, 2017

clojure.spec might be an interesting approach to appeasing Type A personalities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment