3 ms·

>If an object cannot change it follows that it can be shared freely between different threads of execution without fear of concurrent modification. Ok, but the

by runT1ME 16y ago

>If an object cannot change it follows that it can be shared freely between different threads of execution without fear of concurrent modification. Ok, but then is there a reason to have immutability with collections that aren't shared by multiple threads? I love that Clojure is trying to address these big problems, but I'm not convinced they're on the right track.

swannodette 16y ago
Of course there is. You can freely modify values received from other functions without fear of screwing things up further up the chain This is a fairly common idea - (C++ has const, Python tuples, Objective-C immutable collections, etc.) The difference is that in Clojure they're really, really fast since they share structure, giving you ridiculously close to mutable performance in some cases. And you don't have to worry about expensive copy operations or things blowing up because you accidentally casted away from const, etc. It's one of those features that once you're used to, you get a sad face when you look at everything else.
- runT1ME 16y ago
  > You can freely modify values received from other functions without fear of screwing things up further up the chain Thats a neat way of putting it, that it sort of makes the collection 'const'. I'll have to ponder how many bugs/problems are due to that type of error, and if its worth the small performance hit of not using arrays. I'm not sure I'm quite convinced the trade offs are worth it, but considering it further now.
  - swannodette 16y ago
    This also means that you can operate on these data structures with multiple threads. Depending on the number of CPUs you have and the problem domain, you could very well operate more quickly (and safely!) on your data then with mutable data structures.
    - runT1ME 16y ago
      Are you sure? I mean, from what I understand, a linked-list is an 'immutable structure' (in the sense that once a pointer is set, it can never be changed, but it CAN go from empty to something). But, I don't think any old linked list can be safely read and modified from a multithreaded environment without threading issues...
fogus 16y ago
"Ok, but then is there a reason to have immutability with collections that aren't shared by multiple threads?" I think so. What about this scenario: Point foo = new Point(10, 0); frob(foo); zap(foo); What's the value of foo.x? foo.y? I have no idea. In Clojure: (def foo {:x 10, :y 0}) (frob foo) (zap foo) What's the value of foo? {:x 10, :y 0} That certainty is valuable.
- runT1ME 16y ago
  You make an interesting point, one I hadn't considered, which is code readability. It certainly is easier to read. That being said, you could still take a look at what frob and zap do, and figure out what the value of foo was, assuming it was thread local/not shared.

by runT1ME 16y ago

swannodette 16y ago

Of course there is. You can freely modify values received from other functions without fear of screwing things up further up the chain This is a fairly common idea - (C++ has const, Python tuples, Objective-C immutable collections, etc.) The difference is that in Clojure they're really, really fast since they share structure, giving you ridiculously close to mutable performance in some cases. And you don't have to worry about expensive copy operations or things blowing up because you accidentally casted away from const, etc. It's one of those features that once you're used to, you get a sad face when you look at everything else.

runT1ME 16y ago
> You can freely modify values received from other functions without fear of screwing things up further up the chain Thats a neat way of putting it, that it sort of makes the collection 'const'. I'll have to ponder how many bugs/problems are due to that type of error, and if its worth the small performance hit of not using arrays. I'm not sure I'm quite convinced the trade offs are worth it, but considering it further now.
- swannodette 16y ago
  This also means that you can operate on these data structures with multiple threads. Depending on the number of CPUs you have and the problem domain, you could very well operate more quickly (and safely!) on your data then with mutable data structures.
  - runT1ME 16y ago
    Are you sure? I mean, from what I understand, a linked-list is an 'immutable structure' (in the sense that once a pointer is set, it can never be changed, but it CAN go from empty to something). But, I don't think any old linked list can be safely read and modified from a multithreaded environment without threading issues...

fogus 16y ago

"Ok, but then is there a reason to have immutability with collections that aren't shared by multiple threads?" I think so. What about this scenario: Point foo = new Point(10, 0); frob(foo); zap(foo); What's the value of foo.x? foo.y? I have no idea. In Clojure: (def foo {:x 10, :y 0}) (frob foo) (zap foo) What's the value of foo? {:x 10, :y 0} That certainty is valuable.

runT1ME 16y ago
You make an interesting point, one I hadn't considered, which is code readability. It certainly is easier to read. That being said, you could still take a look at what frob and zap do, and figure out what the value of foo was, assuming it was thread local/not shared.