But of course, nothing in Java forces you to use state and side effects. It's a culture problem, again; but if you use Java libraries from within Clojure, you are going to run into those same culture problems.
This is a known problem. There is an in development feature called Pods that will allow you to use nasty mutable Java libraries as well write your own nasty Clojure mutable code (perhaps for performance reasons) w/o destroying concurrency guarantees. I'm looking forward to see how it shakes out.
I meant to write "w/o destroying concurrency guarantees and w/o adding undue complexity". With Pods you don't need explicit locking from what I understand, right?
Now I am beginning to understand why people like Clojure so much. Instead of calling them "state threads", whose Google results turn up academic papers from the early 90s, they call them "pods", whose Google results have nothing to do with programming.
In one company, where Scala is used, they decided to refer to Monads as "comprehensibles" (due to Scala's "for comprehensions", which can be used like Haskell's do statement) in their standard library and documentation: lets everybody use Monads without the knee-jerk reaction of "isn't it some esoteric category thing that Haskell people have to use to do I/O".
Comments
But of course, nothing in Java forces you to use state and side effects. It's a culture problem, again; but if you use Java libraries from within Clojure, you are going to run into those same culture problems.
This is a known problem. There is an in development feature called Pods that will allow you to use nasty mutable Java libraries as well write your own nasty Clojure mutable code (perhaps for performance reasons) w/o destroying concurrency guarantees. I'm looking forward to see how it shakes out.
> w/o destroying concurrency guarantees
Pods will provide more than that since you can provide concurrency guarantees with locks only. However, Pods should additionally help with:
1. Separation of mutation logic and value policy with the Pod handling the underlying juggling 2. Lock order acquisition guarantees
There is more to it than this, but stay tuned for Rich's upcoming talk at the Clojure Conj. :-)
I meant to write "w/o destroying concurrency guarantees and w/o adding undue complexity". With Pods you don't need explicit locking from what I understand, right?
> With Pods you don't need explicit locking from what I understand, right?
That is my understanding yes.
Now I am beginning to understand why people like Clojure so much. Instead of calling them "state threads", whose Google results turn up academic papers from the early 90s, they call them "pods", whose Google results have nothing to do with programming.
Having a short name for commonly used structures aids readability. e.g.
Instead of:I can't really tell if you're being sarcastic or not
In one company, where Scala is used, they decided to refer to Monads as "comprehensibles" (due to Scala's "for comprehensions", which can be used like Haskell's do statement) in their standard library and documentation: lets everybody use Monads without the knee-jerk reaction of "isn't it some esoteric category thing that Haskell people have to use to do I/O".
There is not really alot of documentation yet so you want find any even if you tree more words.