4 ms·

My complaints more reside with issues I ran into with the language itself. Mainly, meaningless exception messages and insane stack traces and poor tooling with

My complaints more reside with issues I ran into with the language itself. Mainly, meaningless exception messages and insane stack traces and poor tooling within my editor of choice (at the time). Also, I take issue with a language that touts itself as purely functional, but then builds itself off of the JVM, forcing you to use objects under the hood. You end up with some kind of weird FP/OO Frankenstein's monster that isn't _really_ FP, but also isn't _really_ OO. Also, since it is on the JVM, there is _no way_ you can actually have truly immutable objects or data structures, as much as Clojure likes to think that is the case. It places a lot of trust on the libraries that make up your program not to go into reflection and do some really annoying mutations. If that is the case, I'd rather just use something like Erlang or Haskell which are _truly_ functional languages, not just an OO system masquerading as a functional language. I _really_ like the syntax of lisp, and Clojure provides some really good extensions of that syntax with the way they do parameters, but in the end I just couldn't get over the issues I had with the core of the language runtime.

diggan 6y ago
Exceptions and stack traces I agree with you can be a bit ridiculous, probably because I'm not used to Java at all. > Also, I take issue with a language that touts itself as purely functional Seems to be a common misconception that still hasn't died. Clojure doesn't tout itself as a "purely functional" language, and as far as I know, never has. It tout itself as a "practical general purpose" language where you can be pure and impure, depending on what you do. What Clojure does advocate for, is the approach that _most_ parts of _most_ programs should functional, but you should be able to go away from that paradigm when required/wanted. > It places a lot of trust on the libraries that make up your program not to go into reflection and do some really annoying mutations Just for the record, in reality and practical terms, I've never had this happen to me. Now I haven't done Clojure development for more than 2 years or something, but if it was a real problem, I'm guessing I would have hit this at least once before. But never have I had a Clojure library unexpectedly mutate things it wasn't supposed to. So yeah, if you're looking for a purely functional language, go with a language that actually tries to be purely functional, because that's not what Clojure aims for, it aims for practicality.
- holtalanm 6y ago
  > Exceptions and stack traces I agree with you can be a bit ridiculous, probably because I'm not used to Java at all. Even if you are used to java, the exceptions and stack traces in Clojure still don't make sense. This is coming from someone who was writing Java in their day job while learning Clojure at home. > Seems to be a common misconception that still hasn't died. Probably because it is not a misconception? Right on the Clojure main site, it states it is a functional language, and that Object Oriented programming is overrated. With the language being built on top of the JVM you _cannot_ avoid objects (the bytecode generated by Clojure is riddled with objects). Clojure is a language that claims to be functional while building its foundations upon one of the most well-known object-oriented systems out there. This is like building a house on top of a concrete foundation, laying some boards over the top to cover it up, and claiming the house is 100% wood. It just....isn't. It also makes the claim that Clojure data structures are immutable. That is 100% not true, as ANY object or data structure can be mutated on the JVM at runtime with reflection. If Clojure truly doesn't aim to be a functional programming language, then maybe they need to update their website. > Just for the record, in reality and practical terms, I've never had this happen to me. If you use any java libraries in your Clojure projects, there is a very high chance you will run into this. One of the 'strengths' that Clojure lays claim to is being able to leverage the Java ecosystem, while at the same time apparently also claiming that you shouldn't use libraries from Java (or if you do, write a wrapper for it).
  - diggan 6y ago
    https://clojure.org/ https://clojure.org/ > Clojure is a robust, practical, and fast programming language with a set of useful features that together form a simple, coherent, and powerful tool. > Clojure is predominantly a functional programming language https://clojure.org/about/functional_programming https://clojure.org/about/functional_programming > Clojure is impure > most parts of most programs should be functional In the end, it doesn't matter what you can do deep down in the JVM. In Clojure land, the data structures you pass around are (mostly) immutable, unless when you use explicitly mutatable data structures.
fulafel 6y ago
What you do mean by making you use objects under the hood? Are you referring to calling into 3rd party Java libraries or the implementation details of Clojure data structures that are under the hood? If the former, the usual thing in Clojure is to make an abstraction layer for them that doesn't leak mutability into your code (or just skipping those libraries altogether if that doesn't work). But of course some things are just inherently side-effectful anyways, where you have to be mindful to isolate/refactor things like IO the edges of the system. (And yep to echo a sibling comment, Clojure is not a purely functional language, and doesn't pretend to be one)
- holtalanm 6y ago
  > What you do mean by making you use objects under the hood? im referring to, at runtime, literally _every_ data structure you use in Clojure is an object.
  - lbj 6y ago
    That doesn't make Clojure any less functional. No matter which language you use, eventually it'll compile to machinecode and thats imperative by nature. Your code however, can be whatever it wants to be. In certain scenarios, the object boxing does come with a high pricetag in terms of performance, but there are always ways around it and usually only a few functions need tweaking. I will concede however, that those few functions typically end up losing their elegance.
  - fulafel 6y ago
    You ar going to have to stick to FP theory and stand back from computers if semantically invisible mutability under the hood disturbs you a lot.

diggan 6y ago

Exceptions and stack traces I agree with you can be a bit ridiculous, probably because I'm not used to Java at all. > Also, I take issue with a language that touts itself as purely functional Seems to be a common misconception that still hasn't died. Clojure doesn't tout itself as a "purely functional" language, and as far as I know, never has. It tout itself as a "practical general purpose" language where you can be pure and impure, depending on what you do. What Clojure does advocate for, is the approach that _most_ parts of _most_ programs should functional, but you should be able to go away from that paradigm when required/wanted. > It places a lot of trust on the libraries that make up your program not to go into reflection and do some really annoying mutations Just for the record, in reality and practical terms, I've never had this happen to me. Now I haven't done Clojure development for more than 2 years or something, but if it was a real problem, I'm guessing I would have hit this at least once before. But never have I had a Clojure library unexpectedly mutate things it wasn't supposed to. So yeah, if you're looking for a purely functional language, go with a language that actually tries to be purely functional, because that's not what Clojure aims for, it aims for practicality.

holtalanm 6y ago
> Exceptions and stack traces I agree with you can be a bit ridiculous, probably because I'm not used to Java at all. Even if you are used to java, the exceptions and stack traces in Clojure still don't make sense. This is coming from someone who was writing Java in their day job while learning Clojure at home. > Seems to be a common misconception that still hasn't died. Probably because it is not a misconception? Right on the Clojure main site, it states it is a functional language, and that Object Oriented programming is overrated. With the language being built on top of the JVM you _cannot_ avoid objects (the bytecode generated by Clojure is riddled with objects). Clojure is a language that claims to be functional while building its foundations upon one of the most well-known object-oriented systems out there. This is like building a house on top of a concrete foundation, laying some boards over the top to cover it up, and claiming the house is 100% wood. It just....isn't. It also makes the claim that Clojure data structures are immutable. That is 100% not true, as ANY object or data structure can be mutated on the JVM at runtime with reflection. If Clojure truly doesn't aim to be a functional programming language, then maybe they need to update their website. > Just for the record, in reality and practical terms, I've never had this happen to me. If you use any java libraries in your Clojure projects, there is a very high chance you will run into this. One of the 'strengths' that Clojure lays claim to is being able to leverage the Java ecosystem, while at the same time apparently also claiming that you shouldn't use libraries from Java (or if you do, write a wrapper for it).
- diggan 6y ago
  https://clojure.org/ https://clojure.org/ > Clojure is a robust, practical, and fast programming language with a set of useful features that together form a simple, coherent, and powerful tool. > Clojure is predominantly a functional programming language https://clojure.org/about/functional_programming https://clojure.org/about/functional_programming > Clojure is impure > most parts of most programs should be functional In the end, it doesn't matter what you can do deep down in the JVM. In Clojure land, the data structures you pass around are (mostly) immutable, unless when you use explicitly mutatable data structures.

fulafel 6y ago

What you do mean by making you use objects under the hood? Are you referring to calling into 3rd party Java libraries or the implementation details of Clojure data structures that are under the hood? If the former, the usual thing in Clojure is to make an abstraction layer for them that doesn't leak mutability into your code (or just skipping those libraries altogether if that doesn't work). But of course some things are just inherently side-effectful anyways, where you have to be mindful to isolate/refactor things like IO the edges of the system. (And yep to echo a sibling comment, Clojure is not a purely functional language, and doesn't pretend to be one)

holtalanm 6y ago
> What you do mean by making you use objects under the hood? im referring to, at runtime, literally _every_ data structure you use in Clojure is an object.
- lbj 6y ago
  That doesn't make Clojure any less functional. No matter which language you use, eventually it'll compile to machinecode and thats imperative by nature. Your code however, can be whatever it wants to be. In certain scenarios, the object boxing does come with a high pricetag in terms of performance, but there are always ways around it and usually only a few functions need tweaking. I will concede however, that those few functions typically end up losing their elegance.
- fulafel 6y ago
  You ar going to have to stick to FP theory and stand back from computers if semantically invisible mutability under the hood disturbs you a lot.