>I suspect this is the real reason Clojure was created, I bet Rich was just really bored.
I notice too that a noticeable number of people pick up Clojure because it's new and shiny. As a longtime Clojurian I find that attitude can be disappointing to run into, like when you realize a growing friendship will die because they're not serious about living in your city.
I don't claim to know the man but the reasons Rich wanted Clojure are quite concrete, well documented, and rational. Java programs of the time were a particularly heinous form of OOP; we should not be surprised that a clever programmer would grow a preference for a dynamic, functional-first style. He found lisp superior (in interactivity, expressiveness, yadda yadda) and wanted to use it professionally.
To work in lisp required delivering something indistinguishable from a JAR (or other mainstream proglang executable). He had the realization that without immutable data structures baked into the language he'd always be subject to Other People's State.
If you think about these points logically they lead pretty straightforwardly to creating a (pragmatically) functional, dynamic, hosted lisp.
I distinctly remember in one of his talks he said words to the effect of “I wrote corporate C++ and Java for years and eventually realised I had to do something else, or else quit the industry”. So he took a year long sabbatical and created Clojure.
Rick wrote jfli, a Java foreign language interface for Common Lisp, before working on Clojure. He was a seasoned lisper, and he wanted to do something both modern and practical.
It's very interesting to go through the bookshelf he read during his sabatical. He was inspired by many languages aside from CL, including Mozart/Oz, AspectJ, and Prolog.
He didn't mean he'd quit out of boredom, he meant he'd quit out of frustration with proglangs that bite you in the ass when writing e.g. concurrent programs
I don't think the particular niche matters, eventually everything becomes being a mundane job.
I know few people that made it in shiny businesses (Serie A and Champions League players like Fabio Liverani and Simone Pepe, or Massimiliano Rosolino swimming gold metal at Olympics) and they all absolutely either hated or found 99.9% of their career an endless marathon of mundane boring activities.
I'm not saying there aren't plenty of exceptions of people that like their job, and jobs that may make it easier, but it looks to me that most of people find their job mundane and boring most of the time.
Agree. Although, as opposed to physical performance activities, be it sports or music, where one of the key activities is to repeat the same thing thousand times, in software, we strive towards not repeating the same thing.
He wasn't writing corporate CRUD apps, he was working on systems like radio broadcasting, voting machines, and Datomic, which involve significant concurrency challenges.
As verbose as Java is, it was even worse 20 years ago. If Kotlin, or C# 3.5+ were the OOP lingua francas at the time, maybe there would have been less need to create something else.
But still, "why not"? The first "alt-lang" I remember was "boo", on the dotnet platform. IDK if they actually meant to popularize it, but it had some cool features C# (and J#) didn't have, so, why not?
My biggest contention with the article is around writing enterprise software
I find solving business problems exciting. I didn’t really get into this business to purely write code or only work with novel technologies. I got into to empower others to do things they otherwise wouldn’t, couldn’t, or didn’t think to do.
To me, the language I work with is such a small slice of the pie. The problems don’t even have to be novel, I simply like approaching a problem and solving it well, and hearing the feedback about how it helps.
I've gotten there, but only after about 25 years in the industry. I think when you're just starting out, you should be excited about different technologies and looking for excuses to try them out.
While I agree with the boredom premise (I was also bored!), the practicality of Clojure was also very important. In fact if I were to deploy something to prod today that is FP, then I either use Scala or Clojure.
Fintech benefits from concurrency, immutability and all, so obviously there is much more nuance to "why fintech uses Clojure".
Doesn't everyone benefit from those things? I didn't follow the fintech call-out here. Is fintech really that much different from other fields? I worked in it for a couple years and the only big difference I saw is how much of a pain all the regulatory hurdles are.
Yep my phrasing was not the best :X. You might know better ("couple years"). However my anecdotal observation is that the end result is that fintech drifts FP (heavy concurrency + immutability, ledgers and all) than your "average" tech. I genuinely don't know why, maybe correctness guarantees and ledgers are just so important.
FWIW I was mostly on the compliance side, so didn't have all that much direct exposure to the transaction side of things. But from the exposure I did have, I didn't see a huge difference. A transaction is a transaction. And the transactions were at the DB layer, so I wouldn't think the atomicity primitives built into the Clojure language would be all that useful.
Like anything, the middle tier should be largely stateless anyway, so using Clojure atomicity primitives in business logic may even be an anti-pattern.
Relatable. I’ve been writing code for soulless corps for about seven years, and it can get exhausting. Add politics and the endless rat race for promotions, and you have a recipe for making good people either really bored or really unhappy.
I need the money to get by, but at the same time, it’s hard to get enthusiastic about writing yet another RPC service or RESTful CRUD. This is partly why ketamine-fueled principal engineers often decide to rearchitect the universe, add Rust to the network layer where it makes no sense, or go ham with SWIG interfaces.
A few things that have worked for me: switching stacks. I started in data science, moved to Python/Node backends, and then switched to distributed systems and databases using Go. Switching teams and companies can help, though more often you just end up trading one bad culture for another.
This is a hard problem to solve, and boredom is real. But the solution isn’t bringing in some funky, untested stuff just for the lolz. Too many teams allow engineers to make the stack look like a mandrill’s face and then suffer the consequences.
new languages are created to push the boundaries for manageable essential complexity, by reducing "accidental" complexity.
clojure's data structures for example enable simpler concurrent work on stupid enterprise data.
however.
I've seen favorite hot fancy XYZ bit rot in large enterprise code bases. the oh so bored original author long gone. boring architecture documentation missing. business critical underdocumented unmaintainable genius code. and I'll kneecap every greenhorn that tries to add such bored kid complexity in my vicinity.
get me right: rust and clojure and friends are great tools and you'll have my back if and where they are needed and add value. then we'll go all in. but no bored kid complexity. go and find yourselves some niche product companies, non enterprise, with hard tricky problems to solve and do genius programming there.
I suspect this is the real reason you wrote this, I bet you were just really bored.
That aside, I got into Clojure because churn everywhere else is exhausting. It's pragmatic with interop, you can use with the new shiny thing without leaving your garden or losing your sanity.
EDIT: you must have forgotten how bad (mostly) it is everywhere else.
Such a low quality article. The whole comment thread is just going to be about the flamebait of "I bet Rich was just really bored". Instead, the author could have listed the reasons they actually "loved it, and by the end I hated it", which would have led to an interesting discussion.
I think it's unfortunate they threw the bit about hickey in there; the part about a shiny new language helping relieve the tedium of enterprise software was a good one
I thought it was self explanatory. It had new idioms I had not yet learned and internalized, so I fully absorbed it. When that was finished, I needed something else to do the same thing with. It's like listening to a song on repeat 10-100 times (depending on the song) when you first hear it. You get everything you can out of it and move on when it's empty.
I’ve watched quite a few of Rich Hickey’s talks and I really do not get the feeling that boredom was a driving factor in his decision to create Clojure
It turns out Clojure is just a really good programming language, not a panacea. If you have to build soul-sucking software, it still sucks even in a great language. Technical cleverness isn't enough to distract you from a bullshit job forever.
> I suspect this is the real reason Clojure was created, I bet Rich was just really bored.
Well he spelled out the motivations in numerous early presentations so I don't think he'd take kindly to the implication they were BS.
I remember a funny quote along the lines of, he felt the concurrent software he'd already written in C++ and Java had required "He-Man" levels of perspiration to actually get correct.
To clarify, I don't mean that Rich didn't also have extremely good reasons to make Clojure, given he was using Java (and maybe C++) in 2007. They're not the best languages now, but they were so broken back then that they practically caused the language revolution that caused Clojure and Go and Node etc to flourish.
I connect with this article very deeply. There was a time when I came to a similar conclusion about rust. That is, its requirements for your code become a puzzle in themselves and make the job a little less boring but when the novelty wares off it’s not so fun. Avoiding boredom at work is a lifelong struggle of mine.
Isn't the draw of mathematics the same way for lots of math-heads, they aren't necessarily interested in how meaningful real-world problems they are solving at the end.
Not sure if Clojure is that special here, it's probably the same with other appealing programming languages that have cultures distinct from default enterprise PL cultures.
This somehow reminds me of that time Jude Law explained to an interviewer that he is very good looking and therefore had to avoid roles for very good looking people in order to be taken seriously as an actor.
I believe Clojure was written to write corpo software that is far more complicated that what most corpo devs are writing. It's just as boring to write basic CRUD apps in any language.
I notice too that a noticeable number of people pick up Clojure because it's new and shiny. As a longtime Clojurian I find that attitude can be disappointing to run into, like when you realize a growing friendship will die because they're not serious about living in your city.
I don't claim to know the man but the reasons Rich wanted Clojure are quite concrete, well documented, and rational. Java programs of the time were a particularly heinous form of OOP; we should not be surprised that a clever programmer would grow a preference for a dynamic, functional-first style. He found lisp superior (in interactivity, expressiveness, yadda yadda) and wanted to use it professionally.
To work in lisp required delivering something indistinguishable from a JAR (or other mainstream proglang executable). He had the realization that without immutable data structures baked into the language he'd always be subject to Other People's State.
If you think about these points logically they lead pretty straightforwardly to creating a (pragmatically) functional, dynamic, hosted lisp.
It's very interesting to go through the bookshelf he read during his sabatical. He was inspired by many languages aside from CL, including Mozart/Oz, AspectJ, and Prolog.
The bookshelf list was originally on Amazon, committed by Rich, but now behind a login wall. However, a Goodreads clone is easy to access: https://www.goodreads.com/list/show/137472.Rich_Hickey_s_Clo...
I know few people that made it in shiny businesses (Serie A and Champions League players like Fabio Liverani and Simone Pepe, or Massimiliano Rosolino swimming gold metal at Olympics) and they all absolutely either hated or found 99.9% of their career an endless marathon of mundane boring activities.
I'm not saying there aren't plenty of exceptions of people that like their job, and jobs that may make it easier, but it looks to me that most of people find their job mundane and boring most of the time.
But still, "why not"? The first "alt-lang" I remember was "boo", on the dotnet platform. IDK if they actually meant to popularize it, but it had some cool features C# (and J#) didn't have, so, why not?
Author is Alfred North Whitehead, the mathematician & philosopher.
Rich has written about the history and motivation behind Clojure here: https://dl.acm.org/doi/pdf/10.1145/3386321
https://youtube.com/watch?v=nD-QHbRWcoM
I find solving business problems exciting. I didn’t really get into this business to purely write code or only work with novel technologies. I got into to empower others to do things they otherwise wouldn’t, couldn’t, or didn’t think to do.
To me, the language I work with is such a small slice of the pie. The problems don’t even have to be novel, I simply like approaching a problem and solving it well, and hearing the feedback about how it helps.
Fintech benefits from concurrency, immutability and all, so obviously there is much more nuance to "why fintech uses Clojure".
Like anything, the middle tier should be largely stateless anyway, so using Clojure atomicity primitives in business logic may even be an anti-pattern.
I need the money to get by, but at the same time, it’s hard to get enthusiastic about writing yet another RPC service or RESTful CRUD. This is partly why ketamine-fueled principal engineers often decide to rearchitect the universe, add Rust to the network layer where it makes no sense, or go ham with SWIG interfaces.
A few things that have worked for me: switching stacks. I started in data science, moved to Python/Node backends, and then switched to distributed systems and databases using Go. Switching teams and companies can help, though more often you just end up trading one bad culture for another.
This is a hard problem to solve, and boredom is real. But the solution isn’t bringing in some funky, untested stuff just for the lolz. Too many teams allow engineers to make the stack look like a mandrill’s face and then suffer the consequences.
But why speculate on Rich's motivations? He has spoken extensively on the subject. (Hint: It's not because he was bored.)
clojure's data structures for example enable simpler concurrent work on stupid enterprise data.
however.
I've seen favorite hot fancy XYZ bit rot in large enterprise code bases. the oh so bored original author long gone. boring architecture documentation missing. business critical underdocumented unmaintainable genius code. and I'll kneecap every greenhorn that tries to add such bored kid complexity in my vicinity.
get me right: rust and clojure and friends are great tools and you'll have my back if and where they are needed and add value. then we'll go all in. but no bored kid complexity. go and find yourselves some niche product companies, non enterprise, with hard tricky problems to solve and do genius programming there.
That aside, I got into Clojure because churn everywhere else is exhausting. It's pragmatic with interop, you can use with the new shiny thing without leaving your garden or losing your sanity.
EDIT: you must have forgotten how bad (mostly) it is everywhere else.
Well he spelled out the motivations in numerous early presentations so I don't think he'd take kindly to the implication they were BS.
I remember a funny quote along the lines of, he felt the concurrent software he'd already written in C++ and Java had required "He-Man" levels of perspiration to actually get correct.
Not sure if Clojure is that special here, it's probably the same with other appealing programming languages that have cultures distinct from default enterprise PL cultures.
I’d rather work on an interesting technical problem in Java than a boring one in Haskell.