5 ms·

Having worked at a company with a large Clojure codebase, I just don't see Clojure growing. It's not well-suited to large projects. The dynamic-ness of it and a

Having worked at a company with a large Clojure codebase, I just don't see Clojure growing. It's not well-suited to large projects. The dynamic-ness of it and awkward parts of the language (macros, protocols, ambiguity of laziness, etc) end up inevitably getting used in ways they aren't intended. The idea that you need "wise programmers" is a really big problem. People leave, institutional knowledge is lost, and then the code archaeology is just more difficult than it would be where types exist as guard rails. I think Clojure looks favorable in comparison to Java still (though perhaps less so). But with Kotlin and Scala as mature alternatives -- and Clojure without a real niche -- it's not what I would reach for.

paultopia 6y ago
Maybe a broader version of this point: clojure tries to be something suited both for industry use at scale and for hobbyists wanting to do freaky-deaky stuff at the same time, but those are fundamentally incompatible. I say this as someone squarely in the latter category who has exactly the opposite problem from you: I love clojure the language and its features, but all the major libraries seem to be written by refugees from Java working at big companies who have a will to massively overengineer everything. I'm thinking of libraries like mount and such which everyone uses for everything, and which I experience as, like, "did you want to inject your dependencies in your injected dependencies? Well first you have to do a quadruple axel inversion of control at the fifth abstraction layer out and use the fooflarb design pattern to delegate your inheritance and you thought you could even find the place in the code where it talks to the database? Good luck, sucker." Like, I always thought the point of a functional language was to not have to do any of that stuff... Like, I vividly remember the first time I used a clojure web framework that brought in all that stuff, and I literally, I'm serious here, could not find where in the code it was actually talking to the database. Just indirection on top of indirection on top of indirection. And when the application I was building on top of that, which was supposed to be quick and dirty, started mysteriously losing data, the only thing I could do was just tear it down and rewrite with Python and flask.
- raspasov 6y ago
  Using a functional language doesn’t make reality and the complexity of state go away (unless you are writing a compiler or a program/system that fully and purely mathematically controls its inputs and outputs).
  - jwatte 6y ago
    A good functional language lets you clearly define, manage, and trace where your code meets reality, though. That kind-of needs strict static type systems, rather than loosey-goosey dynamic tag checking, though. That's IMO the main reason statically type checked languages like C++/Java/etc work much better at large scale than runtime tag checked languages like Python/Clojure/etc.
    - puredanger 6y ago
      I think "needs strict static type systems" is a hypothesis but one with certainly many anecdotal examples to refute it. Most of the studies that have been done (and admittedly these studies are extremely difficult to do well) show lower or similar bug counts in dynamic languages vs static languages. If you've built large scale system with statically type checked languages that solve all these problems, I assume you never had any bugs right? Never needed to write any unit tests?
      - newcrobuzon 6y ago
        Many people don't know this, but you can still commit code that does not compile :D
- burnthrow 6y ago
  It's not fair to point to specific overengineered libraries and say this is the language idiom. Clojure is a small, stable language (few changes over the years) that encourages creation of DSLs through macros. It provides solid ground on which to build the abstraction you want, so it's possible to build these EE-ish indirection nightmares if that's what you need. Clojure's design allows it to serve the needs of both hobbyists and enterprise, but the latter requires strong, disciplined developers who understand to avoid loose, hobbyist code that the language allows, and who will agree on which patterns to use in the codebase (something the hobbyist gets for free mostly). It's a punishing language for a project with high developer turnover.
Xenoamorphous 6y ago
At the company I work for we've found it hard to find Clojure devs. Not sure if this applies everywhere else, but it's definitely seen as a disadvantage of the language here.
- puredanger 6y ago
  Many Clojure companies find it easy to hire smart non-Clojure developers and teach them Clojure. You can learn the basics in a week or two and be a pretty effective Clojure developer (especially if supported in a team) pretty easily.
  - ertucetin 6y ago
    No, you can't (in that timeframe).
    - hangonhn 6y ago
      +1 on that. I've learned Clojure in the past and keep wanting to go back to it but Clojure has been the hardest language for me to become fairly comfortable with. I think it may have to do with its dynamic-ness. There's basically no problem Clojure experts can't find a solution for. Its basic constructs are very powerful but all those solutions are not codified in the language itself. So Clojure has this extra layer of "culture" around it and as a beginner that's very hard to learn without a lot of doing and running into a wall quite a few times. Just when I think I have a grasp on the language, I see a new construct or new way of doing something that's completely alien to me and wasn't in the Clojure book I just read. I've not saying one can't become good at it but it takes a bit and might help to have an expert or two guiding you.
      - huahaiy 6y ago
        As a programmer with decades of experience, it took me half a year to get Clojure, and I had to unlearn a lot. Reading books is not enough, one has to do programming exercises with the language. So I agree that it is harder for experienced people than for young kids fresh from school.
didibus 6y ago
I think it works well in a micro-service world, because in that world, no single component is large, as the large system is built of smaller services. So each service can be a small to medium sized Clojure code base. (At least it does for us at my work). Apart from that, I think one thing that's missing for larger scale Clojure is best practices and common tools, IDEs, frameworks and libraries. When I compare it to Java, Java has so much ingrained best practice and information out there, even junior devs will quickly pick up a book about its design patterns, and all that. And basically everyone uses the same tools and frameworks, its always Spring or Guava, IntelliJ or Eclipse, Jetty or Netty, Log4J or Logback, Jackson, Hibernate, etc. I might agree with you slightly on some of the ackward bits. If transducers had been there from the get go instead of lazy sequences. If named arguments were first class and the compiler could check that the mandatory arguments were passed in. If exceptions were functional, and pattern matching was added to compose them. And if a few more core functions/macros were added for convenience. I think it would facilitate a bit adoption on larger projects.
gorjusborg 6y ago
Kotlin and Scala are closer to Java, so it makes sense it would be an easier sell to Java shops. I don't use Clojure professionally, and have often wondered how well it holds up in companies where avg tenure of an engineer is 2-3 years. I guess that assumes that a tenure of 2-3 years is not a problem in itself.
- mumblemumble 6y ago
  I recently inherited a Clojure codebase whose original developers are all long gone. I'm finding the experience to be a bit like trying to learn how to navigate a city where none of the streets have names. When I was working my way through Clojure for the Brave and True, I really liked all the clever techniques around data-level programming and informal interfaces. Not having to stop to define and name formal types lets you slap things together quickly. But I'm now seeing the where that approach leads to: A codebase where nothing is formally defined, and nothing has a name. I see where there were some efforts to do it by the book, and formalize this stuff by using functions to define an interface. The problem, though, is that we live in an orderly cosmos, and some laws are universal. One of those laws is that people will always take the shortest practical path to get from point A to point B. No matter how politely you ask them not to. So, if a map can be manually hacked to shreds in an ad-hoc manner, it will be manually hacked to shreds in an ad-hoc manner.
  - ballpark 6y ago
    I think I would find it great fun to take a Clojure codebase like this one that you inherited and refactor it to something workable and maintainable! I agree it's probably not a job for a Clojure newbie.
  - ieugen 6y ago
    It will probably be hacked to shreds, but then again the map is most likely immutable ;).

paultopia 6y ago

Maybe a broader version of this point: clojure tries to be something suited both for industry use at scale and for hobbyists wanting to do freaky-deaky stuff at the same time, but those are fundamentally incompatible. I say this as someone squarely in the latter category who has exactly the opposite problem from you: I love clojure the language and its features, but all the major libraries seem to be written by refugees from Java working at big companies who have a will to massively overengineer everything. I'm thinking of libraries like mount and such which everyone uses for everything, and which I experience as, like, "did you want to inject your dependencies in your injected dependencies? Well first you have to do a quadruple axel inversion of control at the fifth abstraction layer out and use the fooflarb design pattern to delegate your inheritance and you thought you could even find the place in the code where it talks to the database? Good luck, sucker." Like, I always thought the point of a functional language was to not have to do any of that stuff... Like, I vividly remember the first time I used a clojure web framework that brought in all that stuff, and I literally, I'm serious here, could not find where in the code it was actually talking to the database. Just indirection on top of indirection on top of indirection. And when the application I was building on top of that, which was supposed to be quick and dirty, started mysteriously losing data, the only thing I could do was just tear it down and rewrite with Python and flask.

raspasov 6y ago
Using a functional language doesn’t make reality and the complexity of state go away (unless you are writing a compiler or a program/system that fully and purely mathematically controls its inputs and outputs).
- jwatte 6y ago
  A good functional language lets you clearly define, manage, and trace where your code meets reality, though. That kind-of needs strict static type systems, rather than loosey-goosey dynamic tag checking, though. That's IMO the main reason statically type checked languages like C++/Java/etc work much better at large scale than runtime tag checked languages like Python/Clojure/etc.
  - puredanger 6y ago
    I think "needs strict static type systems" is a hypothesis but one with certainly many anecdotal examples to refute it. Most of the studies that have been done (and admittedly these studies are extremely difficult to do well) show lower or similar bug counts in dynamic languages vs static languages. If you've built large scale system with statically type checked languages that solve all these problems, I assume you never had any bugs right? Never needed to write any unit tests?
    - newcrobuzon 6y ago
      Many people don't know this, but you can still commit code that does not compile :D
burnthrow 6y ago
It's not fair to point to specific overengineered libraries and say this is the language idiom. Clojure is a small, stable language (few changes over the years) that encourages creation of DSLs through macros. It provides solid ground on which to build the abstraction you want, so it's possible to build these EE-ish indirection nightmares if that's what you need. Clojure's design allows it to serve the needs of both hobbyists and enterprise, but the latter requires strong, disciplined developers who understand to avoid loose, hobbyist code that the language allows, and who will agree on which patterns to use in the codebase (something the hobbyist gets for free mostly). It's a punishing language for a project with high developer turnover.

Xenoamorphous 6y ago

At the company I work for we've found it hard to find Clojure devs. Not sure if this applies everywhere else, but it's definitely seen as a disadvantage of the language here.

puredanger 6y ago
Many Clojure companies find it easy to hire smart non-Clojure developers and teach them Clojure. You can learn the basics in a week or two and be a pretty effective Clojure developer (especially if supported in a team) pretty easily.
- ertucetin 6y ago
  No, you can't (in that timeframe).
  - hangonhn 6y ago
    +1 on that. I've learned Clojure in the past and keep wanting to go back to it but Clojure has been the hardest language for me to become fairly comfortable with. I think it may have to do with its dynamic-ness. There's basically no problem Clojure experts can't find a solution for. Its basic constructs are very powerful but all those solutions are not codified in the language itself. So Clojure has this extra layer of "culture" around it and as a beginner that's very hard to learn without a lot of doing and running into a wall quite a few times. Just when I think I have a grasp on the language, I see a new construct or new way of doing something that's completely alien to me and wasn't in the Clojure book I just read. I've not saying one can't become good at it but it takes a bit and might help to have an expert or two guiding you.
    - huahaiy 6y ago
      As a programmer with decades of experience, it took me half a year to get Clojure, and I had to unlearn a lot. Reading books is not enough, one has to do programming exercises with the language. So I agree that it is harder for experienced people than for young kids fresh from school.

didibus 6y ago

I think it works well in a micro-service world, because in that world, no single component is large, as the large system is built of smaller services. So each service can be a small to medium sized Clojure code base. (At least it does for us at my work). Apart from that, I think one thing that's missing for larger scale Clojure is best practices and common tools, IDEs, frameworks and libraries. When I compare it to Java, Java has so much ingrained best practice and information out there, even junior devs will quickly pick up a book about its design patterns, and all that. And basically everyone uses the same tools and frameworks, its always Spring or Guava, IntelliJ or Eclipse, Jetty or Netty, Log4J or Logback, Jackson, Hibernate, etc. I might agree with you slightly on some of the ackward bits. If transducers had been there from the get go instead of lazy sequences. If named arguments were first class and the compiler could check that the mandatory arguments were passed in. If exceptions were functional, and pattern matching was added to compose them. And if a few more core functions/macros were added for convenience. I think it would facilitate a bit adoption on larger projects.

gorjusborg 6y ago

Kotlin and Scala are closer to Java, so it makes sense it would be an easier sell to Java shops. I don't use Clojure professionally, and have often wondered how well it holds up in companies where avg tenure of an engineer is 2-3 years. I guess that assumes that a tenure of 2-3 years is not a problem in itself.

mumblemumble 6y ago
I recently inherited a Clojure codebase whose original developers are all long gone. I'm finding the experience to be a bit like trying to learn how to navigate a city where none of the streets have names. When I was working my way through Clojure for the Brave and True, I really liked all the clever techniques around data-level programming and informal interfaces. Not having to stop to define and name formal types lets you slap things together quickly. But I'm now seeing the where that approach leads to: A codebase where nothing is formally defined, and nothing has a name. I see where there were some efforts to do it by the book, and formalize this stuff by using functions to define an interface. The problem, though, is that we live in an orderly cosmos, and some laws are universal. One of those laws is that people will always take the shortest practical path to get from point A to point B. No matter how politely you ask them not to. So, if a map can be manually hacked to shreds in an ad-hoc manner, it will be manually hacked to shreds in an ad-hoc manner.
- ballpark 6y ago
  I think I would find it great fun to take a Clojure codebase like this one that you inherited and refactor it to something workable and maintainable! I agree it's probably not a job for a Clojure newbie.
- ieugen 6y ago
  It will probably be hacked to shreds, but then again the map is most likely immutable ;).