Supported by my experience too. My tinnitus is very real, but when I discovered just how much of a psychological component was there, it became more manageable. Little by little I thought I was losing my hearing until I had it checked—it was perfect. The audiologist helped me understand that my constant "tuning in" to the tinnitus was creating the perception that my hearing was being harmed by loud noises and leaving a high-frequency sound in its place. Which is there, but when ignored, it largely disappears.
I think the bottom line with Clojure is it's not an ecosystem well-suited for non-veteran programmers. For as simple as the language is, effectively using Paredit, navigating partially documented libraries, diving into source code to see how things interact—it's tough as a new developer. I don't believe Clojure is overtly hostile to newcomers; it's just crafted by veterans, for veterans. And this is the result.
I consider myself something akin to a veteran. I've been coding for over two decades. Not sure if that qualifies, but anyway.
My point is: it's been with experience that I've come to value ergonomics the most.
And that for me includes having a thriving and focused ecosystem, extensive industry penetration, good and stable tooling, lots of well known codebases learn from, etc.
It was when I was young and inexperienced that I didn't see those as the important bits. I was happy hacking on any half assed editor exploring undocumented APIs and trying to discover patterns and idioms by myself. I was happy to waste time.
I'm not anymore. That's why, while a love Clojure as a language, I don't really use it that much nowadays.
If only time served makes you a veteran, I guess I'm one too, but a lot of it was mediocre time.
I still like hacking on things, but only on hobby projects. When it has something to do with work, I agree. Clojure reminds me of why I liked coding in the first place and I like the way LISP-type languages make me think differently about what I'm doing.
But "in the real world," yeah, I don't want those things. I want something I can build and maintain and be done.
Our experience is that Clojure is a very good language for newcomers to programming as a profession.
In fact, we almost exclusively hire new computer science graduates. None of them had heard of Clojure before joining, and the vast majority of them became useful in 2 weeks, and become productive in a few months. What you described as barriers are the things that got sorted out in the first day when they join.
We do not hire veterans unless they already know Clojure. These people need to unlearn stuff, some of them are resistant to changes, so we don't bother with them.
Folks will naturally ask, "How did you get to this point?"
One insight into successfully walking away from addictions is recognizing that this thing (e.g. alcohol, cigarettes) is unambiguously poisonous. "When I [take/do] this, it will take more than it gives."
Hard to articulate, but it happens when the scales that painted the substance with redeeming qualities falls from your eyes. Sorta like discovering you've entertained a damaging relationship for too long. However much worth this person has, being in a relationship with them is not good for you (or others, usually).
It really wasn't any more complicated than that. I just didn't want to be this drinking person any more and I realized how massive waste of time it has been.
It probably means though that I didn't have any chemical addiction and it certainly helped that I had a things to do that benefited instantly from my decision – my work at that time.
It probably also helped that I was raised up by parents who didn't allow me to blame others when things went wrong with me – "You can't change to world no matter badly it behaves, but you can always do better yourself."
I offered a counter example to the comment author too (Clojure has been wonderful for us), but I do wonder if there is one area where OO languages excel above functional: the shape of the code hints at the shape of the data.
In Lisp, function names describe actions. In OO, classes, inheritance, static properties, and getters and setters give at-a-glance hints as to the shape of the application's data model. In Clojure, we compensate, as you pointed out, with forms of documentation. I'll take that trade-off any day—I never want to go back to classes! But it's perhaps one reason for which Clojure has a reputation of being hard to read by other devs.
since around the early 80s it was common to write large Lisp software using class-oriented or even class-based OOP (a few used also prototype-based OOP). For example Flavors for the MIT Lisp Machine was class-based: multiple-inheritance, mixins, message sending with single dispatch, ... CLOS (the Common Lisp Object System) then changed OOP such that it better fits into Lisp: generic functions with multiple dispatch, classes, multiple-inheritance, meta object protocol, ...
One of the drawbacks of those systems is that the code gets assembled at runtime (though cached) and thus to read and understand code one might need support from class/function browsers.
Oh man, this is not my experience. We may be different because we are a small company, and Clojure is our main language. But, we have a Clojure codebase of 90K lines, and is 10 years old. It has its problems, and while your points about an opaque data model resonate, for us, tests, specs, and assertions provide enough hints to help newcomers. And... where I disagree the most: the quality and professionalism of the developers who work on it are unparalleled. New, senior-level developers, quickly catch on to the system. I am grateful to Clojure __because__ it attracts this caliber of developer.
He argued that if universities cared about diversity their positions on affirmative action would be more dynamic than is commonly accepted. e.g.:
> Affirmative action would also apply more strongly to, say, immigrants from Iran, or Korea, or Israel, than to black people (or anyone else) from our own society.
The examples he uses demonstrate that, in his mind, caring about diversity requires measuring circumstance. You might argue that universities are not so shallow as he's claiming, but I don't believe the article is mere mudslinging.
> their positions on affirmative action would be more dynamic than is commonly accepted
People are already trying to get affirmative action programs dismantled. Making them more complicated would lead to larger surface area, and be easier to attack.
> I don't believe the article is mere mudslinging.
The entire argument of the article is that they don't measure diversity the same way he wants them to measure diversity, and therefore they don't care about it. It never considers that schools consider it differently, or whether his method is consistent, or whether what he proposes has been considered and dismissed.
I hated college. I never finished for the frogs. But I'm a lifelong reader. I don't regret failing to get a degree, but I regret that I wasn't in the right mindset and that I could have used the time to create meaning.
