4 ms·

I don't hear as much about Clojure these days, and I don't know if it's because my reading habits have changed or if the community has become quieter. My impres

by msvan 8y ago

I don't hear as much about Clojure these days, and I don't know if it's because my reading habits have changed or if the community has become quieter. My impression was that other languages have captured the zeitgeist and that the enthusiasm for Clojure has abated. I could be wrong though.

agumonkey 8y ago
It surely changed, I remember how every clojure conj was a source of enlightenement. Reducers, Transducers .. Many Hickey talks were iconic(sic). Now it's not as trendy.. even clojure 1.10 felt ~meh in a way. But taking a bit of distance I thought .. it's better than having people changing the language every 6monthes leading to js fatigue like symptoms. Slow is good. It seems that clojure users are happy with what it is now.
- casion 8y ago
  Clojure 1.10 targeted the #1 most irritating and requested fix to Clojure: Error messages. It's not exciting if you're not a Clojurist, but if you are then 1.10 was one of the coolest releases recently. It doesn't make for the best headlines or hypest hype: "Clojure improves on something people hated about it."
  - agumonkey 8y ago
    Yes, agreed. It's not ~new alien abstraction to make shiny things~ RELEASE.md but it's indeed very useful (especially on a VM hosted language)
casion 8y ago
It's not new and exciting anymore. Same reason you don't hear about Haskell or nearly as much about Rust despite them both being conceptually exciting projects. Hype can be trending, while the underlying thing being hyped, is stable/mature. The aforementioned Haskell is an excellent example of this.
mschaef 8y ago
That's my impression too, and I think it's happening for a combination of reasons. Clojure's no longer the new thing, so its faults don't have the benefit of being hidden behind a lack of experience with the language. Clojure's also a language that rewards long-term investment more than most. That's inherent in all of the mechanisms for abstraction and reuse it provides, but it's not necessarily the kind of thing that's immediately obvious. In the short-term you see the funky syntax and all these linguistic tools you don't quite get, but it takes a while to see how it all fits together into a more productive whole. And by the time you do, you or your team may have moved onto something else because the error messages suck or there's not quite the library you want. I also think languages can suffer because their scope is so limited. There have been times I've thought that I'll switch languages and solve a bunch of problems, only to find out that most of my problems are still there. The requirements are still vague, the team still has its dysfunctions, and the surrounding systems are still unreliable, poorly specified, and run by teams that have no interest in helping because of some organizational dynamic set in place ten years prior. None of this should be a surprise, but the real point is that even a putative perfect programming language can only address a relatively small fraction of the problems that arise in software work. That can make it even more difficult for minority languages like Clojure to produce a positive risk-adjusted return on the investment they require to adopt in a serious way..
vaylian 8y ago
I feel very similar. But I still love Clojure. Sure, the hype has died down/moved elsewhere, but whenever I go back to Clojure it feels like going back to a beautiful place. There's currently nothing new or exiting and that's fine. Sometimes you pick your languages because you know what you can expect from them, because you know them so well.
voidhorse 8y ago
It's an interesting phenomena to look at from a language philosophy perspective. AFAIK, Rich Hickey has advocated for a very pragmatic approach to programming from coljure's inception, and I believe (perhaps excepting the introduction of Spec) the language has stuck to and reflected that philosophy. I believe Hickey has even gone so far as to say it's usually a waste of time to fiddle around with type declarations when you should be solving problems and transforming data (I'm paraphrasing, of course). Contrarily, nearly every other popular modern programming language project (Haskell, Rust, Scala, Crystal, to name a few) hopes to provide nuanced, robust type systems and compile time guarantees--these projects focus less on pragmatics and problem solving and more on correctness and safety. Even elm, which is just a language for building frontends, boasts of its compile time guarantees and elimination of runtime issues using a type system. Clojure is the only recent language that I know of to go against the grain in this regard. That might factor into its decline in popularity--presumably all of these languages are going after type safety and correctness because they are perceived as features people desire these days and clojure never emphasized these properties (some of the things it emphasized instead, such as immutability, problem solving, and interoperability with an existing platform are still important features ,they just don't happen to be as prized right now as correctness/safety and perhaps noiseless/sparse syntax). The introduction of spec can even be perceived as a sort of concession to this popular demand. Even the spec about page hints at the slight[1] incongruence between spec and the overall Clojure philosophy: "However it has always been a guiding principle of Clojure, widely valued and practiced by the community, to simply represent information as data. Thus important properties of Clojure systems are represented and conveyed by the shape and other predicative properties of the data, not captured or checked anywhere since the runtime types are indistinguishable heterogeneous maps and vectors." https://clojure.org/about/spec https://clojure.org/about/spec [1]: Slight because the purposes of spec are not those of a type system or compile checks. What spec does do, however, is introduce some of the bookkeeping sorts of procedures that, in my estimation, the design behind clojure intended to minimize as much as possible.
daxfohl 8y ago
I don't hear as much about anything these days. I feel like it started with Rails, we had a run of years where new languages, frameworks, databases, platforms were coming out every day. The last couple years have been much more ... boring in that respect. Things have consolidated into whatever the big cloud vendors want to support, and even their pace of innovation seems to be slowing dramatically, not too unlike cellphone tech. k8s is probably the buzziest thing, but even that, I have trouble getting very excited about something primarily oriented around ops.
mr_custard 8y ago
My impression is that Clojure has reached maturity and most people that are using it are just quietly getting on with their lives and building useful things with it. From my perspective, it has never been better than it is now and there are a few more things coming this year that are the cherry on the cake.

by msvan 8y ago

agumonkey 8y ago

It surely changed, I remember how every clojure conj was a source of enlightenement. Reducers, Transducers .. Many Hickey talks were iconic(sic). Now it's not as trendy.. even clojure 1.10 felt ~meh in a way. But taking a bit of distance I thought .. it's better than having people changing the language every 6monthes leading to js fatigue like symptoms. Slow is good. It seems that clojure users are happy with what it is now.

casion 8y ago
Clojure 1.10 targeted the #1 most irritating and requested fix to Clojure: Error messages. It's not exciting if you're not a Clojurist, but if you are then 1.10 was one of the coolest releases recently. It doesn't make for the best headlines or hypest hype: "Clojure improves on something people hated about it."
- agumonkey 8y ago
  Yes, agreed. It's not ~new alien abstraction to make shiny things~ RELEASE.md but it's indeed very useful (especially on a VM hosted language)

casion 8y ago

It's not new and exciting anymore. Same reason you don't hear about Haskell or nearly as much about Rust despite them both being conceptually exciting projects. Hype can be trending, while the underlying thing being hyped, is stable/mature. The aforementioned Haskell is an excellent example of this.

mschaef 8y ago

That's my impression too, and I think it's happening for a combination of reasons. Clojure's no longer the new thing, so its faults don't have the benefit of being hidden behind a lack of experience with the language. Clojure's also a language that rewards long-term investment more than most. That's inherent in all of the mechanisms for abstraction and reuse it provides, but it's not necessarily the kind of thing that's immediately obvious. In the short-term you see the funky syntax and all these linguistic tools you don't quite get, but it takes a while to see how it all fits together into a more productive whole. And by the time you do, you or your team may have moved onto something else because the error messages suck or there's not quite the library you want. I also think languages can suffer because their scope is so limited. There have been times I've thought that I'll switch languages and solve a bunch of problems, only to find out that most of my problems are still there. The requirements are still vague, the team still has its dysfunctions, and the surrounding systems are still unreliable, poorly specified, and run by teams that have no interest in helping because of some organizational dynamic set in place ten years prior. None of this should be a surprise, but the real point is that even a putative perfect programming language can only address a relatively small fraction of the problems that arise in software work. That can make it even more difficult for minority languages like Clojure to produce a positive risk-adjusted return on the investment they require to adopt in a serious way..

vaylian 8y ago

I feel very similar. But I still love Clojure. Sure, the hype has died down/moved elsewhere, but whenever I go back to Clojure it feels like going back to a beautiful place. There's currently nothing new or exiting and that's fine. Sometimes you pick your languages because you know what you can expect from them, because you know them so well.

voidhorse 8y ago

It's an interesting phenomena to look at from a language philosophy perspective. AFAIK, Rich Hickey has advocated for a very pragmatic approach to programming from coljure's inception, and I believe (perhaps excepting the introduction of Spec) the language has stuck to and reflected that philosophy. I believe Hickey has even gone so far as to say it's usually a waste of time to fiddle around with type declarations when you should be solving problems and transforming data (I'm paraphrasing, of course). Contrarily, nearly every other popular modern programming language project (Haskell, Rust, Scala, Crystal, to name a few) hopes to provide nuanced, robust type systems and compile time guarantees--these projects focus less on pragmatics and problem solving and more on correctness and safety. Even elm, which is just a language for building frontends, boasts of its compile time guarantees and elimination of runtime issues using a type system. Clojure is the only recent language that I know of to go against the grain in this regard. That might factor into its decline in popularity--presumably all of these languages are going after type safety and correctness because they are perceived as features people desire these days and clojure never emphasized these properties (some of the things it emphasized instead, such as immutability, problem solving, and interoperability with an existing platform are still important features ,they just don't happen to be as prized right now as correctness/safety and perhaps noiseless/sparse syntax). The introduction of spec can even be perceived as a sort of concession to this popular demand. Even the spec about page hints at the slight[1] incongruence between spec and the overall Clojure philosophy: "However it has always been a guiding principle of Clojure, widely valued and practiced by the community, to simply represent information as data. Thus important properties of Clojure systems are represented and conveyed by the shape and other predicative properties of the data, not captured or checked anywhere since the runtime types are indistinguishable heterogeneous maps and vectors." https://clojure.org/about/spec https://clojure.org/about/spec [1]: Slight because the purposes of spec are not those of a type system or compile checks. What spec does do, however, is introduce some of the bookkeeping sorts of procedures that, in my estimation, the design behind clojure intended to minimize as much as possible.

daxfohl 8y ago

I don't hear as much about anything these days. I feel like it started with Rails, we had a run of years where new languages, frameworks, databases, platforms were coming out every day. The last couple years have been much more ... boring in that respect. Things have consolidated into whatever the big cloud vendors want to support, and even their pace of innovation seems to be slowing dramatically, not too unlike cellphone tech. k8s is probably the buzziest thing, but even that, I have trouble getting very excited about something primarily oriented around ops.

mr_custard 8y ago

My impression is that Clojure has reached maturity and most people that are using it are just quietly getting on with their lives and building useful things with it. From my perspective, it has never been better than it is now and there are a few more things coming this year that are the cherry on the cake.