5 ms·

As someone who really really tried to like Clojure, here's the issues I faced, roughly in order starting from biggest: 1. No framework. Clojurists tend to pref

• lgrapenthin 4y ago
  1) There are enough templates and starter packs with documentation. Frameworks have been tried, but they quickly turn out to limit your Clojure given powers. 2) Thats true, but its not leaky abstraction. Clojure never claims to abstract the host away, it embraces it so you can do all low level Java/JS stuff and seemlessly use their libraries without FFIs. 3) You have all Java/JS libs. Most Clojure libs are simply "done", so they get no commits. I don't know of any unmaintend ones. 4) Java is improving? Clojure is mostly done with that already. It was designed long after Java and makes many improvements obsolete.
  • spinningarrow 4y ago
    I think this response is a good illustration of the frustration that I (and I suspect many others) have with Clojure. I’m speaking as someone who’s been excited by it since around 2012, has helped run Clojure meetups, and has tried many times to advocate for its usage. I really _really_ want to love Clojure but the first three points (unfortunately along with the Lisp syntax simply because it’s different enough) alienate too many people from the language and it seems like that’s something that Clojure has at best accepted as not the target audience and at worst is still unwilling to acknowledge.
    • BeFlatXIII 4y ago
      What can be done to address point 3? Push monthly "project still active" commits that bump some minor version number on the docs?
      • e3bc54b2 4y ago
        Clojure has an OS/2 problem in that one of the biggest selling points is Java compatibility. But, clojure is different enough from Java, and that difference is actually another one of biggest selling points, that using Java libs from Clojure is not idiomatic (IMO) and uncomfortable as wrapping/calling Java libs increases through codebase. But, because Java libs already exist and are maintained, there is little incentive to actually implement and improve Clojure libs themselves. The bootstrap became its noose.
        • lgrapenthin 4y ago
          Using Java from Clojure is totally idiomatic. Its very easy to abstract away the ugly interop in one place.
    • synthc 4y ago
      In my experience the Clojure community is pretty tone-deaf when it comes to critisim. The usual response being something along the lines of 'your problem is not a problem, it was meant that way'.
      • e3bc54b2 4y ago
        > In my experience the Clojure community is pretty tone-deaf when it comes to critisim. Its quite frustrating actually. The people who are likely to be greatest advocates of the language (its a new-age Lisp!) are likely to be vocal about its failings, and are also hit with worst reactions like being told their issues are not issues. If you are already part of the team, Clojure folks are very friendly. I want to avoid saying cult, but sometimes it has characteristics of one.
• DeathArrow 4y ago
  >Java is improving faster with more pattern matching, records and functional programming features. Other JVM hosted languages are becoming less appealing Java is the standard for JVM. However, if Java was the perfect tool for any job, no other language would have been implemented over JVM. I would rather use Kotlin than Java, who, to me, seems bloated and ancient. Also Java, the greater programming environment, kind of forces all things to be objects, unneeded inheritance, unneeded abstraction and patterns on top of patterns. I kind of like to use a more data oriented approach than object oriented approach, or pattern oriented approach, or Uncle Bob oriented approach. I strongly think that the shortest path is the best path, the less abstraction the better, the less CPU cycles used for something, the better.
  • tmtvl 4y ago
    The thing is Java is improving, so it has become better suited for a variety of jobs. Clojure is 15 years old, which means when it released Java was at version 1.6. ABCL was separated from J in 2008, when Java was at version. Kotlin was released in 2011, when Java 1.7 was released. Groovy was released in 2007, like Clojure. Scala was released in 2004, when we were at Java 1.5. GNU Kawa was registered on Savannah in 2001, when we had J2SE 1.3. Now just because Java has become a lot better in the interval doesn't mean those languages have no purpose, but if Java in 2001 had all the nice features (streaming API, try with resources, the Optional type, switch expressions,...) it has now then the JVM landscape may very well have looked very different.
    • winkelwagen 4y ago
      Think it’s a different mentality, it’s nice that languages like Java and c# improve at such a rapid pace. But the every improvement also makes it worse and more confusing. I’ve used c# 4 years ago, 4 years of Java am now back to c#. Yes they added nice features on paper but it it made the languages so much more complex to write. The syntax is often similar but different. Just enough for me to need to Google basic syntax. Think most great developers use a subset of any programming language anyway. Can’t wait for c# or Java the good parts
  • pjmlp 4y ago
• spapas82 4y ago
  I definitely agree with 1-3, not so much with 4 since Java follows a completely different paradigm than clojure (typed oo vs dynamic functional) so it boils down to preference.
• fulafel 4y ago
  I think the enthusiasm for a standard framework for each task is a question personal taste and mindset a bit like dynamic languages. Personally I really like that Clojure, Python, and browser targeting languages have less frameworky cultures.
  • cutler 4y ago
    Python less frameworky? . Since when?
    • fulafel 4y ago
      A lot of the high profile python libraries are definitely more libraries than frameworks. Like eg the data side libraries. The default programming experience with the largish standard library and the natural way to pick specific libs of PyPi that don't care about "what framework" you are in. Or in areas that do end up having to do the "don't call us, we'll call you" hollyood principle due to reactive nature, there's at least significant amount of choice and there's not one to rule them all (FastAPI, Flask, Django on the web side for example)
• cutler 4y ago
  Which new functional features? I'm not aware of any since Java 8 and those were pretty feeble. Java still doesn't offer Regex without having to escape metacharacters. That's how primitive it still is.
  • e3bc54b2 4y ago
    Everyone's favourite subset of functional features is different, of course. I am still early in my career. I'm still discovering stuff for first time. I've also found that I am much more likely to use streams, lambdas, Optional and predicates in code compared to my more experienced colleagues. My functions tend to be pure more often, code has more interfaces than inheritance and generally more unit testable. One of the surprising moments was learning Elixir and realising I'm already doing the pipe thing in Java with Optional.map(). Java will never shed its OO skin but it is starting to grow FP muscles in the right places.
  • ttfkam 4y ago
    Flow API (Reactive Streams) https://dev.to/ajiteshtiwari/java-9-flow-api-4e38 https://dev.to/ajiteshtiwari/java-9-flow-api-4e38 Collection factory methods https://openjdk.org/jeps/269 https://openjdk.org/jeps/269 Stream API improvements https://www.javatpoint.com/java-9-stream-api-improvement https://www.javatpoint.com/java-9-stream-api-improvement Honorable mention since not strictly functional, but makes code clearer and integrates well with functional patterns: pattern matching for switch statements https://openjdk.org/jeps/427 https://openjdk.org/jeps/427
  • kaba0 4y ago
    Sum types, records, type inference, so far very primitive pattern matching, but it has a very clear and great goal ahead. And these are only language level changes, the platform has expanded insanely significantly, but that also benefits clojure greatly (which is a good thing, it’s no competition)
• jimbokun 4y ago
  > 1. No framework. Clojurists tend to prefer libraries and I would too, but for a newbie starting out, when every other language seems to have converged on one standard way of doing things (Spring, Rails, Phoenix, Django etc), Clojure just gets in the way with decision fatigue. As someone who codes professionally with Spring frameworks every day, this is a huge selling point for Clojure to me! It is such a huge, opaque, convoluted, complex unpredictable mass of code, that forces broad changes to working code whenever you upgrade to a new major version. One of my favorite Spring debugging anecdotes was where a coworker was trying to find a class from a runtime stack trace in the libraries. Only to discover that the class didn't exist in the source at all, but was dynamically generated by Spring at runtime! Your other points I largely agree with.
  • kaba0 4y ago
    > Only to discover that the class didn't exist in the source at all, but was dynamically generated by Spring at runtime! With all due respect, that’s like numero 0 thing to know about Spring’s AOP which is like the second most important part of Spring after dependency injection.
    • jimbokun 4y ago
      Yes, and that's not a good thing. It breaks down the fundamental debugging model of looking up the code in stack traces and seeing what it does. When an exception is thrown in generated code, what do you do to debug it?
• symfrog 4y ago
  There are active projects that I would categorize as frameworks (e.g. Fulcro)
• yogthos 4y ago
  1) In my experience there is little value in frameworks in modern applications where there tends to be a clear split between the frontend and the backend. The backend is typically structured as a set of stateless services that the frontend queries for resources. Clojure provides excellent tools for building such services. In fact, I'd go as far as to argue that approach taken by frameworks like Rails and Django is an antipattern because it couples your frontend with the backend. This leads to all kinds of problems. For example, it's much easier to horizontally scale your backend when you have stateless services. It's also much easier to add alternative frontends, such as mobile apps, since you already have a service API that can be resued. These are just two concrete examples. 2) Knowing the underlying platform helps, but you certainly don't need any deep knowledge of it. I've worked with excellent Clojure developers who only had superficial knowledge of Java or Js before. 3) I'd argue that Clojure actually does better in this regard than a lot of languages. There are orgs like Clojurists Together that actively fund development and maintenance of Clojure libraries https://www.clojuriststogether.org/ https://www.clojuriststogether.org/ and Nubank themselves fund open source developers as well. Another aspect is that many Clojure libraries are simply doing data transformations. The API accepts a data structure, and returns a different data structure as a result. Such libraries generally don't need a lot of maintenance work. I personally maintain a popular HTMLtemplating library called Selmer and a markdown parser. After the initial feature set was finished, there really hasn't been a lot of work that I've had to do on either library. I do an occasional update to add features, but these have been few and far between lately because these libraries are essentially complete. 4) The difference is that Java keeps growing as a language and that adds cognitive complexity. The bigger the language is the more things you have to keep in your head working with it, the more patterns you have to know, the more styles you end up seeing. All of this makes the language harder to use effectively, and creates room for errors. The value of Clojure is that it's a small and focused language. It's stayed largely the same over the years, and people tend to use a common set of patterns working with it. I'd much rather have a small and expressive language than a large and complex one. Furthermore, Clojure is completely different from Java semantically. It defaults to immutability, and it encourages much better patterns out of the box than Java. Personally, I don't think you can just keep bolting things onto Java to achieve parity with that.