6 ms·

Sort of. But I don't think most people are actually using the concurrency primitives in Clojure all that much. How many systems out there that people are writin

Sort of. But I don't think most people are actually using the concurrency primitives in Clojure all that much. How many systems out there that people are writing make heavy, or even significant, use of concurrency primitives? I'd guess it's definitely the minority. Immutability and programming with data structure literals are what Clojure's all about. Lisp, dynamic, and functional are obviously the other big choices that were made to achieve the overarching goal of the language - simplification. But imo, programming with performant, immutable persistent data structures is the essence of Clojure programming.

adrianm 13y ago
I agree that immutability is central to Clojure and the resulting code definitely reflects that. But managing state, as the OP put it, truly is what Clojure is all about - and immutability falls out of that very deliberate design decision. Let's not confuse the lack of significant STM transactions with refs and its irk with representing the totality of Clojure's concurrency story. Many Clojure libraries make use of atoms, agents, and dynamic scope (which is arguably a concurrency primitive, given the thread locality of the bindings, but not unique to Clojure). While "concurrency is not parallelism", parallelism is a special case of concurrent programs that is often challenging. Clojure's offerings here too are compelling - we have the amazing Reducers library which allows you to write higher order functions for collections that, as Rich Hickey put it, "know how to reduce themselves" - and get parallelism (without locks, without even thinking about it really) on top of that. And then there's the lazy parallel functions - pmap, pcalls, pvalues. Check them out if you haven't. I use Clojure often in a machine learning context with Hadoop/Storm, these abstractions are highly valuable in crafting solutions. Futures/promises are also widely used in Clojure. I'm confused as to why you think data structure literals are part of Clojure's core thesis. Perhaps I just don't understand what mean - are you saying that the fact that the Lisp reader can read strings as data structures as being part of what Clojure is about? If so, that statement would apply to all Lisps, not just Clojure.
- donjigweed 13y ago
  >I'm confused as to why you think data structure literals are part of Clojure's core thesis. I use refs, atoms, and agents very sparingly. You just don't need them very much when you have a suite of performant, immutable data structures (with literals). These data structures, and the assortment of polymorphic functions provided in the language to operate on them, imo are the crux of the language. They dominate the experience of the programmer. As far as managing state goes, they make it so that you rarely have to reach for the explicit constructs listed above.
dkersten 13y ago
Aren't immutability and persistent data structures means of managing state? Note that pron said "its emphasis on managing state, especially in the face of concurrency", not "its emphasis on managing state in the face of concurrency". That is, concurrency is an important area where Clojure's state management really shines, but certainly not the only time that managing state is important. I would say managing state is a key aspect of any complex program, even in the absence of concurrency. I think this actually fits nicely with TFA's assertion about "lightweight data modeling" because managing state and data modelling go hand in hand IMHO. The fact that its lightweight and easy to do (data structure literals also help keep it easy) means that programmers will tend towards this in their solutions. Actually, I believe Rich Hickey says in his talks that its all about managing complexity and making solutions simple through a datacentric approach. I believe that this is, ultimately, what managing state and lightweight data modelling (and by extension Clojure) is all about and its this philosophy that draws me to Clojure.
- donjigweed 13y ago
  Sure, we're in violent agreement. I took pron's statement as if he were referring to the explicit constructs in Clojure for managing state, i.e. refs, atoms, agents, vars. These are in fact about managing state, with or without concurrency in the mix. But in my experience, these represent a very small portion of Clojure programs. Whole libraries are built without using any of them. I think Mark's right about "lightweight data modeling." It's central to Clojure programming.
  - dkersten 13y ago
    We are definitely in agreement then :)

adrianm 13y ago

I agree that immutability is central to Clojure and the resulting code definitely reflects that. But managing state, as the OP put it, truly is what Clojure is all about - and immutability falls out of that very deliberate design decision. Let's not confuse the lack of significant STM transactions with refs and its irk with representing the totality of Clojure's concurrency story. Many Clojure libraries make use of atoms, agents, and dynamic scope (which is arguably a concurrency primitive, given the thread locality of the bindings, but not unique to Clojure). While "concurrency is not parallelism", parallelism is a special case of concurrent programs that is often challenging. Clojure's offerings here too are compelling - we have the amazing Reducers library which allows you to write higher order functions for collections that, as Rich Hickey put it, "know how to reduce themselves" - and get parallelism (without locks, without even thinking about it really) on top of that. And then there's the lazy parallel functions - pmap, pcalls, pvalues. Check them out if you haven't. I use Clojure often in a machine learning context with Hadoop/Storm, these abstractions are highly valuable in crafting solutions. Futures/promises are also widely used in Clojure. I'm confused as to why you think data structure literals are part of Clojure's core thesis. Perhaps I just don't understand what mean - are you saying that the fact that the Lisp reader can read strings as data structures as being part of what Clojure is about? If so, that statement would apply to all Lisps, not just Clojure.

donjigweed 13y ago
>I'm confused as to why you think data structure literals are part of Clojure's core thesis. I use refs, atoms, and agents very sparingly. You just don't need them very much when you have a suite of performant, immutable data structures (with literals). These data structures, and the assortment of polymorphic functions provided in the language to operate on them, imo are the crux of the language. They dominate the experience of the programmer. As far as managing state goes, they make it so that you rarely have to reach for the explicit constructs listed above.

dkersten 13y ago

Aren't immutability and persistent data structures means of managing state? Note that pron said "its emphasis on managing state, especially in the face of concurrency", not "its emphasis on managing state in the face of concurrency". That is, concurrency is an important area where Clojure's state management really shines, but certainly not the only time that managing state is important. I would say managing state is a key aspect of any complex program, even in the absence of concurrency. I think this actually fits nicely with TFA's assertion about "lightweight data modeling" because managing state and data modelling go hand in hand IMHO. The fact that its lightweight and easy to do (data structure literals also help keep it easy) means that programmers will tend towards this in their solutions. Actually, I believe Rich Hickey says in his talks that its all about managing complexity and making solutions simple through a datacentric approach. I believe that this is, ultimately, what managing state and lightweight data modelling (and by extension Clojure) is all about and its this philosophy that draws me to Clojure.

donjigweed 13y ago
Sure, we're in violent agreement. I took pron's statement as if he were referring to the explicit constructs in Clojure for managing state, i.e. refs, atoms, agents, vars. These are in fact about managing state, with or without concurrency in the mix. But in my experience, these represent a very small portion of Clojure programs. Whole libraries are built without using any of them. I think Mark's right about "lightweight data modeling." It's central to Clojure programming.
- dkersten 13y ago
  We are definitely in agreement then :)