5 ms·

An In-Depth Look at Clojure Collections

39 points by Kototama 16y ago

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.
deleted 16y ago
[deleted]
- runevault 16y ago
  This is only about the collections, which are affected by those but not the topic of the article according to the title?
  - DanielRibeiro 16y ago
    You are right.
gtani 16y ago
Joy of Clojure MEAP (draft book from Manning) is coming along really well. 7 of 12 chapters, thru Macro's. (Google for a discount code) http://manning.com/fogus/ http://manning.com/fogus/
- runevault 16y ago
  I haven't read the Macro Chapter yet, but I can say the rest has really helped me understand Clojure a bit better, been reading it since the first MEAP hit. And both authors are very open to feedback so if something doesn't make sense or the like don't be afraid to tell them. They seem very dedicated to helping people better understand and use the language with this book.
  - fogus 16y ago
    The content of the macros section is mostly complete, although there are some tweaks to be done here and there. Of course, if you want to know more about macros we will cover them throughout chapters 8-12 also. However, if you can't wait that long then check out "On Lisp" by pg and "Let over Lambda" by Doug Hoyte. Not only are they the best books on macrology -- they are likely the best possible books on macrology.
    - runevault 16y ago
      Yeah I figured the Macro chapter would be at least fairly complete before you guys published it. Just been too tired to dig into such a dense topic, since even with my limited dabbling in scheme and CL before Clojure I never gained any real skill with macros.
jacquesm 16y ago
In firefox the headings of the sections are very hard to read, the letters run together.

39 points by Kototama 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.

deleted 16y ago

[deleted]

runevault 16y ago
This is only about the collections, which are affected by those but not the topic of the article according to the title?
- DanielRibeiro 16y ago
  You are right.

gtani 16y ago

Joy of Clojure MEAP (draft book from Manning) is coming along really well. 7 of 12 chapters, thru Macro's. (Google for a discount code) http://manning.com/fogus/ http://manning.com/fogus/

runevault 16y ago
I haven't read the Macro Chapter yet, but I can say the rest has really helped me understand Clojure a bit better, been reading it since the first MEAP hit. And both authors are very open to feedback so if something doesn't make sense or the like don't be afraid to tell them. They seem very dedicated to helping people better understand and use the language with this book.
- fogus 16y ago
  The content of the macros section is mostly complete, although there are some tweaks to be done here and there. Of course, if you want to know more about macros we will cover them throughout chapters 8-12 also. However, if you can't wait that long then check out "On Lisp" by pg and "Let over Lambda" by Doug Hoyte. Not only are they the best books on macrology -- they are likely the best possible books on macrology.
  - runevault 16y ago
    Yeah I figured the Macro chapter would be at least fairly complete before you guys published it. Just been too tired to dig into such a dense topic, since even with my limited dabbling in scheme and CL before Clojure I never gained any real skill with macros.

jacquesm 16y ago

In firefox the headings of the sections are very hard to read, the letters run together.