Clojure is for Type B personalities(gist.github.com)
gist.github.com
Clojure is for Type B personalities
https://gist.github.com/oakes/c82cd08821ce444be6bf
43 comments
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.
I am also type B and prefer statically typed languages and the compiler telling me as much as possible what's wrong with my code. I really hate finiding errors at runtime that should have easily been detected by my compiler.
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...
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).
[1]: https://plus.google.com/110981030061712822816/posts/KaSKeg4v...
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).
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.
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.
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.
It's interesting that Yegge places Clojure into the 'conservative' camp whereas the author of this post places it into his equivalent of the 'liberal' camp. Personally, I think that says more about Yegge than the author of this piece, but I suspect that it might also say that the distinctions that each is making might be subtly different.
I think it simply reflects that the distinctions each is making are, to a great degree, subjective and up for debate. See, for example, http://blog.ezyang.com/2012/08/is-haskell-liberal-or-conserv..., which argues that Haskell of all languages is, in a sense, liberal.
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
[2] https://www.youtube.com/watch?v=0GzzFeS5cMc
- 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
[2] https://www.youtube.com/watch?v=0GzzFeS5cMc
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.
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.
Pop psychology meets programmer mythology.
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..
Somehow related: "The bipolar LISP programmer" (http://www.lambdassociates.org/blog/bipolar.htm).
Yep, that's me.
A vs B is a matter of reaction to stress (as it affects the heart), not organizational prowess.
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.
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.
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.
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.
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.
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.
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.
So, "Clojure is for slobs?" Because that's what it sounds like the article is saying...
I didn't see it that way. More spontaneous and un-predictable is what I got.
Laziness, sloppy code conventions, cheap beer, gas station pastries...
The cheap beer I mentioned was Yuengling, which is definitely not for slobs =)
[deleted]
counterexample, I am type B but I like rigid languages.
I find this offensive for some reason.
But the error message though...
I dont agree with this at all
Loved it. Thanks!
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.
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.
I don't know about putting them on a team. I've always thought of the dichotomy as being properly between "engine" code and "script" code: the engine defines your platform by implementing the mechanism, and the script defines your business use-case by implementing the policy.
See, e.g., game engines vs. Lua scripting, or the LAMP stack vs. PHP scripting, or the implementation of framework DSLs like Rails vs. their usage. Type A people write libraries and generic servers; Type B people write apps by consuming and wrapping and configuring and composing libraries and generic servers—writing the classic "glue code."
I think a lot of the misshapen cultural dynamics in most software projects are the result of Type A people thinking its their job to implement policy (in the engine), and Type B people thinking it's their job to implement mechanism (in the app.) It works best when these people aren't on a team, but instead have a clearly-defined idea of where their responsibilities end and passing the buck begins.
See, e.g., game engines vs. Lua scripting, or the LAMP stack vs. PHP scripting, or the implementation of framework DSLs like Rails vs. their usage. Type A people write libraries and generic servers; Type B people write apps by consuming and wrapping and configuring and composing libraries and generic servers—writing the classic "glue code."
I think a lot of the misshapen cultural dynamics in most software projects are the result of Type A people thinking its their job to implement policy (in the engine), and Type B people thinking it's their job to implement mechanism (in the app.) It works best when these people aren't on a team, but instead have a clearly-defined idea of where their responsibilities end and passing the buck begins.
Link?
Column was published before the web was invented (in the 1980s), so I have no idea.
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.
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.
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.
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.
>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.
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.
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.
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.
Yup, you type B's are glorious, righteous, and so often misunderstood people. We, type A's, are pretty much only good for writing unit tests.
you left out that type B's are also disorganized and messy and I never said type B are glorious and righteous.
Like the article says nobody is right or wrong. I just simply put the case out there that one personality is a good fit for different stages of the company.
Like the article says nobody is right or wrong. I just simply put the case out there that one personality is a good fit for different stages of the company.
More likely, your "type B" programmer will build a half-assed MVP with 20% of the initial features that will break every 5 seconds and thus the "million dollars paying startup" will lose their customers to the saner competition.
I will also very much question your visionaries/maintenance distinction. Many dynamic languages today are influenced by technology developed in academia. This is because the "type B coder" you are speaking of lacks the theoretical foundation to build sound abstractions that are proven to not break.
I would describe myself very much as a "type B" personality - I'm completely disorganized, messy and lazy. I've event gotten into (physical) fights with flatmates over this.
And precisely because of this, I'm choosing technology that takes away all the rigid bookkeeping and context switching that is needed when writing anything more complex than a basic Bootstrap/Angular/whatever bullshit CRUD app.
This is because refactoring is a lot harder in a language without structure. I would never dare rip out the base data structures and replace them with something completely different in a project with more than 2kloc in a language without types. While in a logically sound language I do that daily and don't even care - a perfect fit for my "type B" personality.
I will also very much question your visionaries/maintenance distinction. Many dynamic languages today are influenced by technology developed in academia. This is because the "type B coder" you are speaking of lacks the theoretical foundation to build sound abstractions that are proven to not break.
I would describe myself very much as a "type B" personality - I'm completely disorganized, messy and lazy. I've event gotten into (physical) fights with flatmates over this.
And precisely because of this, I'm choosing technology that takes away all the rigid bookkeeping and context switching that is needed when writing anything more complex than a basic Bootstrap/Angular/whatever bullshit CRUD app.
This is because refactoring is a lot harder in a language without structure. I would never dare rip out the base data structures and replace them with something completely different in a project with more than 2kloc in a language without types. While in a logically sound language I do that daily and don't even care - a perfect fit for my "type B" personality.
However, I prefer statically typed languages like Scala, as it is easier for me to compensate for lack of internal discipline with external constraints.