Clojure has a dirty little secret

which just backs up the comments about your first language being easier for you.

my first language was C. I’d say the same things about it that you’ve said about clojure. it’s an incredibly simple language to learn and it’s easy to get things done if you use it right. people who struggle with it do so because they learned something else first. in college, we did everything from writing our own unix shells to traveling salesman approximations, all in C. as undergrads. in the same amount of time people are now given to do them in python.

so, no, clojure is not objectively the easiest language. immutable is a horrible default. immutable by default is on par with making everything an object. just because it’s good in certain situations doesn’t mean it should be used for everything.

the dirty secret of clojure is that interest in it peaked in 2014 and has been sharply declining since. the highest paid stuff is because of how few developers are using it, with most of them being senior level, so the average is higher. a senior JavaScript dev will make just as much as a senior clojure dev. I know someone with less than 5 years experience that just got hired for $120k per year to do js. pay is based on skill, experience, and what the company is willing to offer, not the language. period.

it’s always hard for people to grasp that their favorite tool isn’t favored by everyone. a lot of people tried clojure back when it had a lot of hype. the vast majority rejected it. that’s reality. if it were objectively easier to get things done, that wouldn’t be the case. most devs primarily care about productivity and getting things done and aren’t tied to any language. if clojure made things easier, they would’ve adopted it. they didn’t. it’s that simple. acknowledge, move on.

Well, obviously I disagree. Clojure wasn’t my first language. My first language was C++. And I did mostly Java in college. And I was fairly conversant in Python and Ruby as well before finding Clojure. I’d been dabbling in languages since I was a teenager, for a good 15 years before Clojure came out. I still considered myself a “beginner” though. I’d never written anything significant - no big projects - never did any professional programming, nor did I really want to. None of them really “clicked” and frankly I wasn’t very interested in programming full time.

When Clojure came out, it was just super easy to use and it was easy for me to understand. I was in the army at the time and I used Clojure to push patches out across a series of FOBs in Afghanistan and automate other basic tasks. It was just the easiest way to script things out and get things done, since there was a JVM on every box. After the army, I decided not to go into programming since most jobs for programming seemed like they sucked just way too much. Professional Java programming? No thanks! lol

So I went into Cybersecurity down in DC. Even there though, I used Clojure to scratch all my itches, collating security event data - pretty much like excel on steroids - kinda like my secret weapon. 5 or 6 years in of using Clojure as mostly a hobby language, I still considered myself a “beginner” at that point, not having developed any code professionally or built anything really large or complicated. I definitely loved to write in it, which was one of the only languages at the time I could say that about - enough that I’d actually considered joining the programming industry. There just weren’t any Clojure jobs at the time :confused:

Then, around 2014/2015 (what you call Clojure’s peak), there were finally some Clojure jobs starting to pop up - enough to considered getting a job in Clojure. That’s when I decided to transition into programming full time and at that point is when I’d consider myself a “mid-level” programmer - not quite beginner, not quite expert. Since then, it seems like the Clojure job pool has been steadily growing more and more. Opportunities and pay has only gone up, AFAICT.

I’d say what peaked in 2014 was an insane level of excitement. I was watching a lot of languages over the prior decade. Many had some interest and excitement, but the level of irrational exuberance around the Clojure programming language was unparalleled, perhaps in the history on languages. Like @zcaudate pointed out, tons of big ideas were being tried and it just inspired a lot of people to create really amazing things. It spawned “papers we love” and other conference and fostered a popular culture of “going back to the love of the craft” kinda thing. I don’t think that level of excitement is sustainable for any language or open source tool - the slowing down of that was inevitable. Y’all keep lamenting that “It’s not like it used to be, Clojure sucks now” but the industry has kept growing and new things keep coming out and Clojure tools have been slowing polishing into more industrial strength things. Seems like too many older hats in the community have a hangover from all their previous excitement and now they’re depressed that same level of “excitement” isn’t there. But no language has that amount of excitement. It’s frankly not normal lol.

Calling C easy seems like hyperbole lol. Sure, assembly is the easiest language of all :smile: If that were true though, I’d still be doing cybersecurity, I assure you.

6 Likes

In my circles, C has a reputation for being easy. I cannot think of an easier language than C when it comes to compiled GC-less languages.

C++ and Rust are both harder, they have a much bigger surface, a bunch of additional constructs to learn about and understand, etc.

I can’t speak for Fortran, Crystal, Forth, D, Pascal, Cobol, Ada etc. But I feel, appart from Pascal, from what I know, they all seem like they’d have more to learn and thus be harder then C.

But “easy” is a personal feeling, it’s not an objective characteristic. For example, I did not find C++ or Rust harder than C, they all feel easy to me.

“Easy” also doesn’t mean free of bug, performant, expressive, concise, extendable, readable, maintainable, resilient, fault tolerant, etc.

In my experience “easy” doesn’t even mean productive or quick to implement things in. I’ve seen people do stuff in less time or similar time and call them “hard” for example.

I think “easy”/“hard” is often about how much mental effort and thinking someone had to do. If it wasn’t mind memory, but they had to think and reason, and weren’t sure they were doing it right, weren’t sure it was going to work, didn’t know how to assess if they were on the right track or not, etc.

Which means most things get easier with experience. But some things could remain harder if there’s just a lot of things to know and remember, you can find yourself more quickly forgetting, so the feeling of “hard” can stick around longer.

That means for example auto-complete has a big impact on how easy you feel something is. Even if it ends up taking you longer to implement something, that you didn’t have to remember any of the keywords, syntax, field names, etc. can make it feel easier, because you didn’t have to think about as many things.

I’m not sure how that applies to Clojure, I do feel it seems to invoke more mental effort from some people, and I think it’s just because of familiarity at first, or some people might just have a different way of thinking that doesn’t jive with it. But also for some it seems to take them less mental effort, and maybe their way of thinking is more naturally in-line with it.

What’s weird too is, “easy”/“hard” doesn’t always map to “fun”/“not fun”. Hard can often be more enjoyable and exciting. So I don’t think it directly relates with motivation, but it can.

So to the OPs point, it’s possible the people who find it hard have been more vocal, you could just as well justify calling it easy if you find a group who all felt it was easy for them.

If there’s a vocal group of people calling it hard, they can give the wrong impression, they can also drown out the ones calling it easy.

In Python, the group that finds it hard might not feel safe speaking up, worried to be seen as the odd one out, if it’s so easy for everyone else it seems, you don’t want to expose yourself as having had a hard time with it.

In Clojure we might have the other issue, people like me who found it easy, I feel bad saying it to others, there’s so much talk of people finding it so hard, I don’t want to make them feel bad or sound condescending if I say I thought it was pretty easy.

Absolutely, and that’s inline with Clojure 100%. You got immutable as the first thing you should try, and then you can fallback to controlled mutability, or if you need more, go to uncontrolled mutable.

In that way it’s very different to have a default then to only have one construct available.

Java has everything as an Object because it gives you no other options. Objects are not the default, they’re the only choice.

Clojure just gently leans you to try immutable first, but has all the fallback options you might need when they’re appropriate.

I still contend immutable is always the first thing you should attempt to use, and you need good reasons to use something else instead, as opposed to the other way around.

Said with zero data. I absolutely grasp that different people can favor different things. But both saying that a lot of people tried and, and that the vast majority rejected it is BS.

Off course “a lot” is a weasel word, but in actuality a greater majority of professional programmers never tried Clojure, and most likely this is true as well of dabling or student programmers.

As for rejecting it, that’s a strong insinuation, they might have stopped using it, that doesn’t imply they’ve rejected it. Given a better paid job, with a more interesting product and a good pleasant team as compared to their current job, would it being in Clojure be enough for the majority of people who tried Clojure to turn down the job? I too have no data, but I honestly highly doubt that.

This reasoning seems flawed. From my personal experience and all the anecdotes of every programmer I know about, this isn’t the driving factor for the language you use at work. Even I don’t use the “easiest” option. I pick the most appropriate option given a series of criteria, for languages it’s most often what is standard already in the company and what do new hires already know, when I get any influence on the choice of matter, and most of the time I don’t have any influence on the matter.

Just my 2 cents.

3 Likes

That’s an important point too I think.

It takes a certain kind of person to enjoy programming, for most languages. Like some very hard computer games, certain people just enjoy putting themselves through the stress of a very hard puzzle. That’s why many people shy away from programming, I think. They just don’t appreciate that level of difficult puzzling.

But there are brilliant people that do other things, in science and elsewhere, and thus python becomes the “data science” language, because very smart people need tools that don’t force them to be smart in puzzles unrelated to their problem domain.

I think Clojure is a shorter path for that crowd though. Again, algo-based “hey look at me, I’m like an english sentence” languages are snake-oil when it comes to easiness, in the long run, even Python. Once you want to do something with lots of threads or concurrency or shared data, or a thing that hasn’t already been done, you’re waiting for someone else to build bindings for you. Not as much in Clojure. The difficulty of other languages make them an island, disconnected from other professions. I think Clojure is less of an island far away, for people of other creative passions.

It so happens that I enjoy puzzling out hard problems, like making a bloom filter or whathaveyou, in Clojure, but maybe that’s just because I think it’ll be of more use to creative-types on the main-land, not on some language island that 99% of “mere mortals” won’t ever be able to learn and be interested in.

I’m not trying to disparage folks of mutable/algol heritage. Again, it’s all lipstick over the same pig and when you get past the syntax and some levels of semantic abstraction, you realize we’re all puzzling over the same problems on the same hardware and it doesn’t really matter what language you use, for those hardest of problems. And at that point you’re thinking like a software engineer and language choices aren’t as important. I just think it’s really hard for software engineers with an algo heritage to realize just how much closer Clojure is to the main-land of creativity compared to the mutable algo islands of other languages. To that extent I agree with @daslu that Clojure could be a much better Python than Python for data science folks.

2 Likes

That’s a really cool way of framing it. Reading about your experience, mine was pretty similar in terms of being able to build and design things. I remember getting all the Professional Java/Python books and being such an OO snob - laughing at my friend’s PHP codebase that only had functions. SQL? How could anyone write in such a nonsensical language. Turns out, I just didn’t know how to program. I was a consumer of other people’s code in the ecosystem and had a bias towards code marketed as ‘Object Orientated’.


Clojure taught me how to construct big systems and a big part of that was the functional paradigm and the immutable datastructures. I used to think that big systems needed to be designed in one go by a genius but gradually as I started putting out my own libraries, I learnt that big systems are a just combination of little systems. The better one got at combining and the better one got a writing and testing little systems - the better one got at building big systems.

It really was like playing with legos but one had to design the blocks and the connectors along with the actual thing to build. And then build it, test it out and then write a blog post to publicise what had been built. I also started to collect obscure one-liners that other people blogged about that were super interesting as well collecting together answers on stackoverflow as functions. Those formed the basis for the util library I still use today.


Having said that, it is my belief that at some point in time the language positioned itself to be much more attractive to the corporate world than to the everyday programmer, and in doing that, it risks losing both.

‘Back in the day’, there was a library for pretty much anything. Fast forward a couple of years, 90% of those libraries that are now abandoned/unmaintained, the more useful one being adopted by cli-commons. Easy come, easy go. The only real chance of a library surviving/still being maintained by the original author/team is if they were a runtime (cljs, shadow-cljs clojerl, babashka) or a library released by a clojure consultancy. Why would anyone else actually want to release open source clojure?


Ultimately, I think it’s the lack of respect and alienation to creators other than the clojure.core team that turned people away from the language. I remember the guard rails comment to one of the leading people that popularised the use of clojure. I remember the mow my lawn comment aimed at I don’t know who. I remember dismissing all of those comments as jokes until it happened to me.

I remember hoping to bring attention to schema as a community supported defacto standard, writing a blog post, being blasted for it and being told to grow up. I remember the effect that comment had was to give the entire clojure community carte blanche to jump on my back. weasel was a word that stood out to me the most, used by someone in the community I had actually respected until then. I remember colleges I respected telling me that I would not work in clojure ever again until I gave a public apology. I remember talking to early creators who contributed greatly to the ecosystem about their similar experiences when wanting to affect change, as well as why they had already left the language by that time. I remember the Open Source is not about you gist only 3 months after my blog post. That rant probably damaged clojure more than any single incident I can remember because it sucked the joy right out of the language.

I’ll still go back to that one word - hubris.

1 Like

Well, I think you can both A) feel free to do and say risky things, like shitting on a clojure.core effort or whatever, and B) don’t get offended when others shit on you.

I’ve take jabs at Rich. I’ve probably offended most of the clojure.core people and I reserve the right to do so in the future :slight_smile: I still love them and consider them great people and friends, regardless what some of them may or may not think about me. Doesn’t matter to me. Life is too short.

@seancorfield and I talk shit at each other all the time and I know he’ll have a beer with me at the conj bar regardless. That was the way it used to be “back in the day” … We could insult each other and not be so sensitive about it. People telling you you’ll never work in Clojure again just because of a blog post, even if it was wrong-headed, stupid or whatever, is the reason lots of social tech communities lost some of their spirit over the last decade.

Why would anyone else actually want to release open source clojure?

Why would any one want to release any open source?

For any code I release, the most ideal situation would be for someone else to take the idea and go support, maintain and “own” it. And that really takes a team of people. Being a singular open source maintainer is too much work and not enough payoff. So 90% of what I release I intend to be of pedagogical value. Please just learn from my thing and then go build something with it I can use. And that’s the main utility of 90% of the “old” libraries out there now. If you need to know how to do a thing in Clojure, there’s now a huge library of code out there you can go look at. That’s fantastic. More often then not, we don’t want to use the whole library anyway - just one function from it. Your utils lib is great for that. Sorry, but most of the time I don’t want to bring in a whole “the missing parts” lib just to use the one fn I need from it.

My inmesh lib is a little different, as it’s pretty unique and its blocking semantics could open the door to lots of other needed things, like stepping debuggers and a host of other things, but still I’d rather not be the maintainer and code owner long term. I’d much rather someone else go build a bigger and better version - and then maybe somebody else makes an even better version. I’m fine with just being a part of the inspiration process. But things that get used by everyone really should be maintained by entire teams, like cognitect and other code shops, like you say.

I have this one lib that auto-transduces and auto-paralellizes, just by changing a ->> to a =>>. I’m also a team lead over a borrower-facing mortgage application that has billions of dollars flowing through it a year. I did an extensive analysis of what benefit it would bring to our code base and in the end, I decided not to bring it into our codebase. I’m not going to introduce an entirely new idiom to our codebase and workflow just for a 3% gain - and we’re an embarrassingly non-big-data application - small sequences and small data in short bursts - maybe if we were building adhoc ETL jobs… point is, as a team lead, I’m well within my rights to bring in new tech where I think it’s necessary. But I’m not going to impose my own open source babies on my shop out of pride. I want to keep mainline semantics and highly maintained bits that are backed up by entire teams in the code, as much as possible. inmesh, we may end up dogfooding and supporting, as it’s a kind of thing that really should exist as it opens up many possibilities and should really exist.

Anyway, I’ve got hubris, you’ve got hubris, the clojure.core people have hubris, we can all be shitty people and that’s okay. This is all just typical infighting BS that is okay and people used not not bat an eye at it. It’s no big deal. And I don’t mind you airing grievances because it shouldn’t be a big deal for people to do so. By all means, have at it. But I’d encourage all of us, while throwing mud and slapping each other with dead fish, not to lose sight of the bigger picture of the awesome tech that we’re building. It really is awesome. It really is working and the industry is growing. You’re a prick and I’m a jerk and this is awesome tech and everything is fine :slight_smile:

3 Likes

…I was offended. But I’m still here aren’t I?

Time puts a lot of things into perspective. Rich telling me to ‘grow up’ was a really good thing for me in hindsight. ‘Open Source is not about you’ was probably not a good thing in hindsight for open source clojure, even though it was madly applauded at the time.

What I wanted to point out was the loss of really important people contributing to the growth of the language - for various reasons. I wanted to present want I had experienced first hand a few of the reasons why people left the language.

If you want to call it ‘shitting on clojure’ and ‘venting’. Fine. But you are missing the point. I’m not upset about that. I’m upset that the language that most influenced how I write code has remained pretty stale for the last couple of years.


I made the choice to discontinue my libs primarily for the reasons you mentioned. No one really wants a ‘missing parts’ lib, especially if cut and paste were easier. So it wasn’t offering me any benefit to continue to publish. And I’ve been happy with that choice - again influenced by ‘open source is not about you’.


So I’m really happy that you are supporting open source clojure and applaud you for it. As far as I see it, you’re the minority and it would be great if there were more support for creators such as yourself.

2 Likes

A lot of these sentiments seem to come from an expectation of acquiring the same level of respect as those seemly enjoyed by the clojure.core team for whatever work one does in Clojure. Unfortunately, that is quite unrealistic, and the labeling of entitlement for such expectation by some was indeed not inappropriate.

The Clojure community is not some kind of fan club. For example, the clojure.core team does not enjoy as much unduly respect as you think they do. A lot of things the core team put out did not gain much traction, and people openly questioned their choices all the time.

In any case, if one put things out, one should be prepared to be critiqued by people and be prepared to defend yourself. One cannot be both thin-faced and expecting respect at the same time. It is as simple as that.

Finally, one does not have to rationalize one’s own choice by pretending that choice is the one chosen by the majority. It is not a popularity contest. Why do you care if you are the minority or the majority? If you don’t want to publish Clojure libraries any more. Fine. Do not pretend that whoever does is only the minority. That does no good for anybody. What would be the right thing to do? Walk away quietly. That’s the right thing to do. If you care about the community at all. You should be doing that.

1 Like

No, the core team created the language and popularised the language, they deserve their roses.

I’m not talking about the code that I wrote. I’m talking about libraries like ‘midje’ and others that I really don’t want to name that just ended up with the guy that wrote it leaving. Sustainability is something that clojure libs don’t have.

Wow. I’m lucky I never listened to guys like you.

First off, I’ll just put my “Moderator Hat” on for a minute and caution folks to remain civil and not let this thread get too heated. There are some parts of some posts here that aren’t really in the spirit of ClojureVerse – we have various tools to slow this thread down and chill it out a bit but I’d rather we don’t need to use them.

Second, as an open source maintainer (for nearly thirty years at this point), I’ll say that it can be a brutal road to travel because everyone has opinions about how you should do things and there is definitely a lot of entitlement out there about what you “should do” to support some arbitrary user’s needs and wants.

I mostly maintain open source projects because I need them in my day-to-day work. It’s why I took over and then handed off CongoMongo to another maintainer – we started using MongoDB heavily and then we stopped using it. It’s why I am only notionally a maintainer of clj-time these days and why I’ve archived several of my own projects. But it’s also why I’m a very active and passionate maintainer of next.jdbc and HoneySQL. I also maintain five Contrib libraries (although one of them we do not use at work).

If someone criticizes one of your projects, it’s hard not to take it personally, but as long as they’re only attacking the idea and not the person, we should still be able to have healthy debates and not stoop to ad hominem attacks.

7 Likes

You may be right, you may be wrong.

For a long time, I didn’t think clojure.core should pick favorites, just like Linus avoided picking favorite distros more often than not.

I thought Rich’s “open source is not about you” was spot on, but maybe Rich did go too far and my agreement is misplaced. But I think it’s okay for Rich to be wrong about that and for me to be wrong and if I’d rather not play in some game where people can’t make mistakes. If people are going to take their toys and go home cause they’re mad, I’m just going to have to assume that’s what’s best for all of us.

I’ll commiserate with you about the sadness of seeing some people go, but like you said, you’re still here. I’m still here. Lots of others are still here and there’s lots of new people. It’d be nice of some old-hats came back. But, again, it’s not about them. I know where you’re coming from though.

4 Likes

Thanks. I’ll stop here. Glad we’re on the same page.

2 Likes

Sometimes, messages need to be put out in more plain form to get across. Dancing around may not be the best option. For example, sometimes, being here may not be better than not being here, for everyone’s sake.

I understand that Clojureverse wants to be a welcoming place, but the effect seems to be the opposite. Because I felt I would rather post things in Reddit than in here.

The reason is simple, whenever I post anything here, I was always gotten quickly shut down. People seem to care more about the appearance of politeness than anything else in here.

It’s weird.

Being polite is always about appearance. Politeness is important here for all the same reasons we raise our children to be polite to others. It is definitely not weird.

Disagreeing politely is not impolite, and providing counter arguments politely is not impolite. Either you are polite or you are not.

There is a difference in how contrarian you can be in a discussion, depending on how well you know the other party / parties. The extra context provided by knowing people well allows for more freedom in the discussions, and modifies what is considered polite.

1 Like

Aaaaanyway, Clojure is easy… Communitying, not so much lol

4 Likes

Everyone reacts differently, but this convo here, this is why I love the Clojure community.

I hang out in other language communities, and they’re just not as fun, you don’t have interesting conversations, neither about software, nor ethics, nor any of that stuff. They tend to get flooded with basic beginner questions and turn into sub-par stackoverflows.

Once in a while they got some interesting topics, but they can also tend to foster the conversation, honestly, I feel they are either more toxic, or too moderated.

This convo, this is learning for me, seeing all the perspective, discussing a hard topic, it threads a thin line, sometimes you got a troll here and there, but overall I personally find the Clojure community can discuss hard topics effectively.

That said, everyone has their own experience, and definitely personal insults is something I’m strongly against, so it really sucks if this is what you experienced. I’m glad you’re still here.

I really appreciate people who have strong opposite views in the community, when someone defends mutability, OO, and has the opinion that immutability, REPL, dynamic typing is bad, and has a lot of issues, this is great for me, challenging my opinions is a great way for me to battle test them, and increase my chances of being more right with my choices at the end of the day. It’s also good practice for me to put the effort in articulating my intuitions, which can be a hard thing to do, but a great skill to have as an engineer, it helps with knowing how to influence your peers at work, your leadership and your business partners.

I’m not sure I know who are all the great people who were pushed out, if they truly had good things to contribute, that’s a shame, but if its more that they were discontent with the reception their ideas got and left, I don’t feel you can fault anyone, people are not entitled to praise nor servitude. If the idea just didn’t interest people it just didn’t.

4 Likes

If we assume “Clojure is easy” — what actions should that lead us to take?

Does it lead to different actions than assuming “Clojure is hard”?

I’m asking because I’m looking for something I can do right now :slight_smile:

3 Likes

Maybe one possible way to figure out how easy it is, and whether there still are some gaps in making it easy, could be trying to teach it to people of diverse backgrounds.

2 Likes

Even a “Clojure for Kids” thing. I think that would be a really cool effort.

I guess my “call to action” of this post originally was that when your in conversation with folks, online or elsewhere, and someone brings up a “downside” of Clojure being that it is hard, try to push back on that a little. Explain that many people find it to be the easiest language, many of whom considered themselves “beginners.”

I think a really cool DS/ML project at this intersection could be a version of 4clojure that auto generates questions and answers. Also, a much more nuanced pedagogical hierarchy - so the first 10 or 20 “levels” of advancement should be achievable by children. Such a system should be able to keep auto-generating questions and answers until the learner “graduates” beyond the current level.

3 Likes