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.
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.
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.