3 ms·

This has to be one of the biggest misconceptions about Clojure. Clojure is first and foremost about managing state - the concurrency benefits fall out of that.

This has to be one of the biggest misconceptions about Clojure. Clojure is first and foremost about managing state - the concurrency benefits fall out of that. Most software could benefit from managed state. EDIT: though I don't agree with your viewpoint (why limit state management to your db and webserver, don't you want the same guarantees for your app logic as well?), I did not downvote you.

va_coder 15y ago
I don't think so. Clojure is about using more verbs and less nouns (that store state). It's designed to manage LESS state, if any at all.
- abedra 15y ago
  Clojure is about simplicity. It helps you get to the point. It helps you eliminate unnecessary state, and when necessary, helps you manage the state that is.
  - va_coder 15y ago
    "eliminate unnecesary state" What is it you said that I didn't?
sbt 15y ago
I agree. At work, I fill our Java codebase with 'final' keywords because it helps me make more assumptions about code I didn't write.
thom 15y ago
I'm using Clojure at my company, and I love it. However, I regularly come back to this point in arguments with my other Clojure-loving friends. Clojure is a wonderful way of managing state in a _single JVM_. I think it has totally cracked this problem, and its model is the model I want to see everywhere for managing concurrency in a single process. My problem is that I feel it's solving a problem I don't really have. I'm not making desktop software, so I just don't care about using a single machine's cores safely and efficiently. While you claim most software could benefit from managed state, my assumption is that the majority of people looking at Clojure today are thinking of it for server software. The issues there immediately spread beyond a single process, and suddenly all the magic of Clojure stops being relevant. To scale my app I'm using multiple processes across multiple machines, and while I'd love something similar to the Clojure model to apply there, it just doesn't. I feel like Clojure has popped up at an unfortunate time when desktop apps are only just thinking seriously about concurrency, but server apps have already moved beyond the model that works within a single JVM. So I really don't know what its sweet-spot is. All that said, I should repeat that I love the language and have found it an exceedingly productive way to work on the JVM. I just wish it solved even bigger, cleverer problems than it already does. ;)
- swannodette 15y ago
  Your argument goes both ways. i.e. Erlang while fantastic for distributed concurrency isn't so hot when you need to solve each portion of the problem in the shortest amount of time possible on each machine in your cluster utilizing all the cores you have without having to write a boatload of code.

va_coder 15y ago

I don't think so. Clojure is about using more verbs and less nouns (that store state). It's designed to manage LESS state, if any at all.

abedra 15y ago
Clojure is about simplicity. It helps you get to the point. It helps you eliminate unnecessary state, and when necessary, helps you manage the state that is.
- va_coder 15y ago
  "eliminate unnecesary state" What is it you said that I didn't?

sbt 15y ago

I agree. At work, I fill our Java codebase with 'final' keywords because it helps me make more assumptions about code I didn't write.

thom 15y ago

I'm using Clojure at my company, and I love it. However, I regularly come back to this point in arguments with my other Clojure-loving friends. Clojure is a wonderful way of managing state in a _single JVM_. I think it has totally cracked this problem, and its model is the model I want to see everywhere for managing concurrency in a single process. My problem is that I feel it's solving a problem I don't really have. I'm not making desktop software, so I just don't care about using a single machine's cores safely and efficiently. While you claim most software could benefit from managed state, my assumption is that the majority of people looking at Clojure today are thinking of it for server software. The issues there immediately spread beyond a single process, and suddenly all the magic of Clojure stops being relevant. To scale my app I'm using multiple processes across multiple machines, and while I'd love something similar to the Clojure model to apply there, it just doesn't. I feel like Clojure has popped up at an unfortunate time when desktop apps are only just thinking seriously about concurrency, but server apps have already moved beyond the model that works within a single JVM. So I really don't know what its sweet-spot is. All that said, I should repeat that I love the language and have found it an exceedingly productive way to work on the JVM. I just wish it solved even bigger, cleverer problems than it already does. ;)

swannodette 15y ago
Your argument goes both ways. i.e. Erlang while fantastic for distributed concurrency isn't so hot when you need to solve each portion of the problem in the shortest amount of time possible on each machine in your cluster utilizing all the cores you have without having to write a boatload of code.