
Clojure is for Type B personalities - priyatam
https://gist.github.com/oakes/c82cd08821ce444be6bf
======
atemerev
I am a type B person (if this designation even makes sense), and have a
diagnosed ADD.

However, I prefer statically typed languages like Scala, as it is easier for
me to compensate for lack of internal discipline with external constraints.

~~~
sanderjd
This was my thought too: this has it backwards. I would rather have a computer
do all the "Type A" perfectionism for me, thank you very much, so that I can
carry on being my "Type B" self.

------
rntz
This is basically reinventing Steve Yegge's analysis in [1] of programmers
into "conservative" (risk-averse, prioritize safety) and "liberal" (accepting
of risk, prioritize expressivity), except less polarizing (because it doesn't
involve political comparisons) and less thorough. Oakes also calls for
reconciliation, while Yegge tips his hand as a hardcore "liberal".

[1]:
[https://plus.google.com/110981030061712822816/posts/KaSKeg4v...](https://plus.google.com/110981030061712822816/posts/KaSKeg4vQtz)

They're both vaguely accurate but break down if you try to credit them with
too much explanatory power (as Yegge does, IMO, but Oakes doesn't seem quite
as reductionist).

~~~
clock_tower
Both, to me, sound like reinventions of ESR's "the cathedral and the bazaar".
I like those definitions and the things they imply: bazaar-style work is
simple, easy, and fast, it doesn't require much capital, but it doesn't scale
past a certain size -- and it's not going to produce an architecture that can
withstand firebombing 700 years after ground was broken for it.

I think most people can say pretty accurately whether they're in the "open for
business by Tuesday" model of software development or the "700 years and
undreamt-of threats" model... But if your product becomes a surprise hit,
that's when you refactor your chaotic bazaar into a clean, legible, highly
maintainable cathedral.

~~~
rntz
Cathedral and Bazaar are about different ways of organizing projects;
Liberal/conservative or Type B/Type A are about individual programmer
preferences. So they're not the same thing, although there's some amount of
sympathy between them - one might expect liberal/type-B personalities to be
attracted to bazaar work and conservative/type-A personalities to prefer
cathedral work. But I don't know to what extent this is true, or testable.

------
ronjouch
If you're interested in Clojure, the gist author (Zach Oakes) maintains a few
cool projects [1]:

\- play-clj, a Clojure game library

\- Nightcode, an IDE for Clojure

\- Nightweb, an anonymous P2P social network in Clojure

and (non-Clojure) - SolidOak, an IDE for Rust

Also, his "Making Games at Runtime with Clojure" talk [2] is great.

[1] [https://github.com/oakes](https://github.com/oakes)

[2]
[https://www.youtube.com/watch?v=0GzzFeS5cMc](https://www.youtube.com/watch?v=0GzzFeS5cMc)

------
slapresta
While I understand the sentiment, this conflates up-front design with compile-
time safety, and opposes the latter to "quick, spontaneous changes". However,
I feel that my iteration loop gets tighter thanks to compile-time safety,
since I don't even have to run my application and test it to find most of its
errors.

~~~
sanderjd
Yes! It is _so_ much easier to write a bunch of aspirational code when you
know the compiler is going to tell you exactly why all of the stuff that can't
possibly work won't work, so that you can go fix it.

------
hartror
Pop psychology meets programmer mythology.

~~~
galfarragem
My experience fits in his model though. I'm type A and more into ML languages
than Lisp. Maybe not strictly type A: Java is too boring for me..

~~~
kevinwang
I guess we could actually test this empirically with a survey.

~~~
meshuggah
Maybe we should. I am a type A, but I prefer Scheme to any other language in
existence. I actually came to Scheme via Clojure.

------
vorador
Somehow related: "The bipolar LISP programmer"
([http://www.lambdassociates.org/blog/bipolar.htm](http://www.lambdassociates.org/blog/bipolar.htm)).

~~~
such_a_casual
Yep, that's me.

------
PaulHoule
A vs B is a matter of reaction to stress (as it affects the heart), not
organizational prowess.

------
jagtesh
I'd argue that these might be polar examples and that a lot of people (maybe
even the majority) fall somewhere in between. I for one cannot imagine being
like the Clojure author, committing scratch-pad code into repo. At the same
time, I despise the levels of complexity C++, Java and C# have introduced.
Ruby and Javascript (and sometimes Python, Bash) are my goto. However, I like
to organize things, keep them DRY. A project like Rails is extremely well
architected for an interpreted language based on the authors observations. I
highly doubt that it is an outlier.

------
js8
I have to say, I was trying to learn Clojure (instead of Common Lisp) and
actually fell in love with Haskell when a friend explained that I don't have
to write the type signatures - almost at all. Indeed; previously, I was
rigorously doing type signatures on all functions in Haskell, and found it
very annoying.

The only downside of that was it made sometimes harder to figure out the
error. When you get run time type error, you can do the traces on the values
and see where it happens more easily. In case of static typing error, you
cannot even start the program. But perhaps this just requires some better
practice.

And I also experienced the "when it compiles, almost correct" proverb from
Haskell community.

The other thing that converted me to Haskell from Lisp was that I learned
(theoretically, so far) about how to write interpreters using free monads. And
you get type checking with it.

~~~
mamcx
Type inference is cool for write fast but defeat the point of have a type
system (IMHO).

I'm using F#, and without a IDE that tell me what kind of crazy type is the
code I'm looking right know I can't function.

I have used delphi (love it!) and write the types is so minimal, and the
benefit of clarity are great. I use a lot of python, I'm used to be unsecure
about what exactly the types are. I use F#, and I'm even more unsecure about
it. Is kind of infurating that the compiler _know_ what the types _are_ , but
all of that is _hidden_ to me!

P.D: Type-inference is the thing I like less from F#. All the rest is great to
me (Pattern matching, AGDT, etc).

I wish the editor show me the types in _read mode_ but I can write without
type all in _write mode_. So, I write "a + b" and then when move out the line,
the editor show "a:int + b:int" or something like that. That could truly be
the best thing about the 2 worlds.

------
mathgenius
Pretty great article. I've thought alot about these issues aswell. The tension
between the two types is difficult to deal with and I don't really know any
solution, apart from mutual respect.

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).

The two types struggle to connect: type-A just sees the B as a big mess, and
type-B sees the A as technically correct but missing the point entirely.

------
clock_tower
So, "Clojure is for slobs?" Because that's what it sounds like the article is
saying...

~~~
pacomerh
I didn't see it that way. More spontaneous and un-predictable is what I got.

~~~
clock_tower
Laziness, sloppy code conventions, cheap beer, gas station pastries...

~~~
gw
The cheap beer I mentioned was Yuengling, which is definitely not for slobs =)

------
blt
counterexample, I am type B but I like rigid languages.

------
elwell
I find this offensive for some reason.

------
cwhy
But the error message though...

------
limeyx
I dont agree with this at all

------
mikejholly
Loved it. Thanks!

------
WildUtah
Robert X Cringely said that programmers are divided into nerds and geeks. The
nerds do the wrong thing well and the geeks do the right thing badly.

The reason computers are a revolutionary productive technology is that when
you put them together on a team they don't do what you would expect and do the
wrong things badly but instead do the right things well.

I don't know how to use that story to write better Clojure, though.

~~~
such_a_casual
Link?

~~~
WildUtah
Column was published before the web was invented (in the 1980s), so I have no
idea.

------
jorgecurio
so much of this hit home. I'm disorganized. I like to just get at the meat of
the problem. I don't sit on my hands shopping for programming patterns to use.

I compare the process of creating software much like pottery when you start
out with clay it's not clear what the end result is going to be. But as you
play around with it something forms, and you impose more structure and clear
cut features with refactoring.

type b coders like us get a lot of shit for eccentric decisions that
ultimately lead to breakthrough ideas or features but type A coders is almost
always dominating with logic and aggression I see tensions between developers.

If what the article says holds true, I would say Type A coders are more for
maintenance and Type B coders are the visionaries. Type B is the engineer that
gets paid millions for writing MVPs as a early CTO while Type A engineers
tendency to compete on everything leads to burn out and lower salary. Likewise
Type B would be horrible in a corporate environment where as Type A would do
well.

~~~
sanderjd
This is an extremely high-and-mighty perspective. If this is truly your
worldview, you may do well to take a step back and consider upping your
humility and compassion levels. Next time someone gives you shit for your
eccentric decisions, maybe try _really_ asking yourself whether they might be
right and you might be wrong. Next time you see somebody reading up on
programming techniques and best practices, maybe consider that they might be
wisely availing themselves of learning resources beyond themselves, rather
than "sit[ting] on [their] hands".

I do agree with you that the tendency to compete to be the most "right" is a
problem amongst programmers, but I don't really see that it fits into this
whole (contrived, IMO) "Type A" vs. "Type B" thing. I've seen plenty of
bikeshedding amongst the organized and the disorganized alike.

~~~
jorgecurio
>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.

Almost early on in any startup phase, you want a type B to quickly build MVP
without drama and then hiring type A to refactor it.

I've seen a startup get all worked up about structures, spacings, unit tests
when they don't even have a customer yet, can't ship fast enough because of
all these bottlenecks introduced by Type A architect.

In large corporation Type A would thrive where as the Type B wouldn't so I
just don't see why you take what I said to the heart.

~~~
sanderjd
I really didn't take what you said "to the heart". I was more hoping to nudge
you toward a greater self awareness. (I'm also being pretty high-and-mighty by
thinking that's my prerogative, so there we are.)

The truth of the matter is that knowing when and how to build an MVP quickly
without wasting time on the wrong things and knowing when and how to create
reliable and maintainable software is _all_ part of your job as a software
developer. Choosing one or the other as "that's just how I am" is shirking
responsibility.

