3 ms·

If any of you need motivation to go and learn it! Please do it! You will never regret invest time in clojure. Agree that Clojure is a good language to learn. I

If any of you need motivation to go and learn it! Please do it! You will never regret invest time in clojure. Agree that Clojure is a good language to learn. If you plan to use it beyond educational purposes though, expect to hit many walls when/if you plan to write real world apps with it. The foundations are there but the ecosystem isn't. Someone will mention the Java libraries, but at that point you are not really writing Clojure. Also, be prepared to deal with the cultish obsession of the community. They have very strong opinions but will never elaborate.

ertian 6y ago
If I'm working with Java libraries, I'd much rather do it from Clojure. You do end up having to write something like an interface for any library you're using--but to be honest, you tend to do that in Java anyway.
- jcadam 6y ago
  In some cases, depending on the library, writing a small Java class makes the interfacing easier.
Random_ernest 6y ago
Libpython.clj allows python interop. So you have the entire ecosystem of python and Java at your hands. I would argue that this should suffice to go far beyond educational purposes.
daveliepmann 6y ago
>Someone will mention the Java libraries, but at that point you are not really writing Clojure. Uh, Clojure was literally written from day one on the founding principle of Java interop? Using Java libraries from a functional lisp is literally the reason Clojure exists.
nocman 6y ago
> Also, be prepared to deal with the cultish obsession of the community. They have very strong opinions but will never elaborate. I'm curious to know what "cultish obsession" you are referring to. Also, what strong opinions have you been unable to get elaboration on?
- Kalium 6y ago
  When working with Clojure teams, I personally ran into "libraries, not frameworks!". Interesting maxim, but I never found any kind of satisfactory explanation. There was a general deep-seated belief that Clojure was the right solution for every problem, with a similar amount of elaboration.
  - lostcolony 6y ago
    I have that maxim for...basically every language I use, though, despite never using Clojure. There's a little wiggle room; I think it's largely dependent on what you define each by, but basically anything that forces me to write my app in a certain way, and limits how easily I can slip in things that are clearly libraries, become liabilities, and I would prefer to avoid. Obviously that's hand-wavey; there are plenty of things that people will call frameworks that nevertheless dictate very little, if anything, about the structure of your code, and which are easy to get to play nicely with other libraries. But there are also plenty that...don't. But to play it safe, I look at things that described to me as frameworks with far more suspicion than I do things described as libraries.
    - Kalium 6y ago
      It's definitely a wonderful goal to aspire to, and ideal for small or personal projects. In my experience, I've found this particular approach to be, at times, of unfortunately limited value in developing and maintaining enterprise systems. A previous employer of mine was a Clojure-heavy shop. There were multiple teams. A Clojure dev going from one team to another could expect to find themselves in a very different stack with very different conventions to do very similar-looking web service tasks. In essence, each team had composed their own under-documented framework.
      - lostcolony 6y ago
        I've had no issues with it in enterprise systems. Note that it doesn't mean you can't use a framework...it just means prioritizing ones that feel more like libraries, and minimize their surface area. I've worked in a shop that had 8 dev teams, all working on different systems, all in Node, using Express. We favored standardizing, but standardizing on something easily extensible. The middleware approach made including non-standard things really easy; if I needed to include some custom authentication library that wasn't written for Express, it was trivial to do it; a couple lines of glue was all it would take, even if it included some initialization. Compare that to a Spring, say. I have to know about the framework's authentication interfaces, implement a comparatively large amount of glue in terms of those interfaces and configuration, and even more hoops to jump through if there's state I need to initialize first for the underlying library. That's what I mean. I'm not arguing for or against standardization, but extensibility and minimal cognitive overhead in extending it.
kimi 6y ago
In this case I have been writing a lot of Java in the last few years. Nothing wrong with it, all the extra parentheses made it pretty good.

ertian 6y ago

If I'm working with Java libraries, I'd much rather do it from Clojure. You do end up having to write something like an interface for any library you're using--but to be honest, you tend to do that in Java anyway.

jcadam 6y ago
In some cases, depending on the library, writing a small Java class makes the interfacing easier.

Random_ernest 6y ago

Libpython.clj allows python interop. So you have the entire ecosystem of python and Java at your hands. I would argue that this should suffice to go far beyond educational purposes.

daveliepmann 6y ago

>Someone will mention the Java libraries, but at that point you are not really writing Clojure. Uh, Clojure was literally written from day one on the founding principle of Java interop? Using Java libraries from a functional lisp is literally the reason Clojure exists.

nocman 6y ago

> Also, be prepared to deal with the cultish obsession of the community. They have very strong opinions but will never elaborate. I'm curious to know what "cultish obsession" you are referring to. Also, what strong opinions have you been unable to get elaboration on?

Kalium 6y ago
When working with Clojure teams, I personally ran into "libraries, not frameworks!". Interesting maxim, but I never found any kind of satisfactory explanation. There was a general deep-seated belief that Clojure was the right solution for every problem, with a similar amount of elaboration.
- lostcolony 6y ago
  I have that maxim for...basically every language I use, though, despite never using Clojure. There's a little wiggle room; I think it's largely dependent on what you define each by, but basically anything that forces me to write my app in a certain way, and limits how easily I can slip in things that are clearly libraries, become liabilities, and I would prefer to avoid. Obviously that's hand-wavey; there are plenty of things that people will call frameworks that nevertheless dictate very little, if anything, about the structure of your code, and which are easy to get to play nicely with other libraries. But there are also plenty that...don't. But to play it safe, I look at things that described to me as frameworks with far more suspicion than I do things described as libraries.
  - Kalium 6y ago
    It's definitely a wonderful goal to aspire to, and ideal for small or personal projects. In my experience, I've found this particular approach to be, at times, of unfortunately limited value in developing and maintaining enterprise systems. A previous employer of mine was a Clojure-heavy shop. There were multiple teams. A Clojure dev going from one team to another could expect to find themselves in a very different stack with very different conventions to do very similar-looking web service tasks. In essence, each team had composed their own under-documented framework.
    - lostcolony 6y ago
      I've had no issues with it in enterprise systems. Note that it doesn't mean you can't use a framework...it just means prioritizing ones that feel more like libraries, and minimize their surface area. I've worked in a shop that had 8 dev teams, all working on different systems, all in Node, using Express. We favored standardizing, but standardizing on something easily extensible. The middleware approach made including non-standard things really easy; if I needed to include some custom authentication library that wasn't written for Express, it was trivial to do it; a couple lines of glue was all it would take, even if it included some initialization. Compare that to a Spring, say. I have to know about the framework's authentication interfaces, implement a comparatively large amount of glue in terms of those interfaces and configuration, and even more hoops to jump through if there's state I need to initialize first for the underlying library. That's what I mean. I'm not arguing for or against standardization, but extensibility and minimal cognitive overhead in extending it.

kimi 6y ago

In this case I have been writing a lot of Java in the last few years. Nothing wrong with it, all the extra parentheses made it pretty good.