I might be damaged from years of Java, but my main imagined issue with Clojure is the lack of a component system. Call it OCaml functors or OOP classes, but instantiating a component with replaceable components as input is what I personally need for large scale programming. To make things more concrete, let's say you are writing an integration to another system using HTTP. On the surface you'll have functions like `fetch-album-information` and they will internally use a HTTP client. How do you handle TLS configuration, HTTP connection pooling, etc. and make the function testable and lifecycle-managed to allow clean shutdown? The easy answer is to parameterise the function with another function that takes care of all of that. But that function will need to come from somewhere and I imagine threading these kind of functions explicitly through your entire program will make it less than palatable. The alternative of using globals that can be replaced in testing carry all the usual problems that global variables have but seems to be what many settle with judging from Clojure code on GitHub. It seems like others are feeling this pain and have invented band-aid solutions like https://github.com/stuartsierra/component but this is something I think needs a first-class solution to encourage this kind of programming.
Why Clojure?
91–100 of 202 posts
Re: Why Clojure?
#92Earlier quoted context omitted.
Clojure has something like an extendable type system called Spec. We can create our own types lol
I am quite familiar with Spec. In my few years of professional Clojure experience, working with people who write Clojure every day, and enjoy it, and advocate using things like Spec, I have never actually seen anyone do it successfully in practice. I understand the idealist world view is seductive — we'll be discipined, we'll write the tests, we'll make good use of Spec, etc etc. In reality, I have never seen this ha…
We use spec a lot, using orchestra’s defn-spec combined with expound for improved error reporting.
It’s not a type system, but it’s very concise and easy to add validations to important functions. This removes the “lazy and undisciplined” part of the equation.
Re: Why Clojure?
#93> 1. Economy of expression
Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now.
I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain of what it's doing or how it's doing it. If this thing breaks or stops working, we're screwed.
The problem is that the author, like most of us, found great joy in writing very few characters to express very big ideas. Clojure let him do that to an extreme degree. And I'm sure if you were sitting beside the author, with him explaining these dense expressions, you would be enlightened at the elegance and beauty of this language.
Sadly, I was not.
I'm sure Clojure is a lovely language. But it lets you write a Voynich manuscript that compiles.
Re: Why Clojure?
#94The response to "but is it slow" is pretty disappointingly bad. > No. Clojure is not slow. Oh, look, it’s not C. It’s not assembler. If nanoseconds are your concern than you probably don’t want Clojure in your innermost loops. You also probably don’t want Java, or C#. But 99.9% of the software we write nowadays has no need of nanosecond performance. I’ve built a real time, GUI based, animated space war game using Clo…
The biggest thing keeping me from ever seriously learning Clojure is the JVM. Slow startup time means I'd never use Clojure for "scripts", and I certainly don't want to have to manage the JVM in production scenarios, so when would I use Clojure? If there was a native version that could produce static binaries like Go/Nim/Rust I'd be much more interested to learn it.
Re: Why Clojure?
#95Earlier quoted context omitted.
> by far the best programming language I've ever used Would love to hear why? What is that make Clojure such a good experience for you?
Not the grandparent, but I realized the other day that I'm at nine years of clojure, so... What's made clojure so great, imo, is its unicorn status as a principled-yet-practical language. That "principled" part is not worthless---it means that a lot of great minds are drawn to it. Before react took over the world, clojure folks were already taking steps in that direction. A lot of other things. The "sequence" as a co…
What is GUI programming like in Clojure? What libraries exist, and what paradigms are used? E.g. is it more like React or is it more like Gtk/Qt?
Re: Why Clojure?
#96This is all nice and exciting until you start to 1) Debug code, the high density of clojure code means that this is really painful. 2) Read code you wrote a while back. The high density of clojure code means that this is really painful.
I find the high density makes debugging easier (up to a point) when combined with immutability. Being able to quickly stub/swap out a referentially transparent branch of the code while knowing you haven't more broadly changed behavior can be really useful. Also code density means you're more likely to be pointed to the line (or within a few lines) of where the actual problem is. This may be personal preference but I'd rather debug 1-5 dense line than 20-50 sparse lines given the equivalent code quality and functionality.
Re: Why Clojure?
#97This is all nice and exciting until you start to 1) Debug code, the high density of clojure code means that this is really painful. 2) Read code you wrote a while back. The high density of clojure code means that this is really painful.
Anecdotally, clojure seems to have a very nice subset of the language which is easy to debug and expressive enough to solve most problems effectively and naturally.
What makes clojure exciting [for me] isn't the ability to build efficient transducers or create powerful custom syntax or build complicated value-level dispatch hierarchies (and in my experience, although they are cool and fun to use, all of these things certainly do make for code which is hard to understand and harder to debug), it's the comprehensive and easily-composable functional programming primitives, excellent built-in immutable data structures with intuitive shared interfaces, practical and (for the most part) straightforward approach to polymorphism, and sane approach to concurrency.
Re: Why Clojure?
#98> Now let’s compare that to the equivalent Java program:
public class SquaresOfIntegers {
public static void main(String[] args) {
for (int i=0; iFirst of all, Java is famously verbose. Nobody is impressed when a language is more concise than Java.
But even ignoring that, the comparison isn't representative. The enclosing class and 'main' function aren't needed for every additional fragment of code, so it probably shouldn't be counted here.
Re: Why Clojure?
#99> 1. Economy of expression Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now. I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain…
> ML library (...) It was written 4 years ago by a research scientist (...)
Do you believe the language is the issue, been written by someone not trained on software engineering practices?
Would you find untested (I'm betting this code you inherited lacks tests, from experience working w/ ML research code artifacts) verbose Algol-family code any easier to understand?
Re: Why Clojure?
#100> 1. Economy of expression Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now. I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain…
You should be annoyed with the less than ideal coding practices of your former colleague not the language.