An In-Depth Look at Clojure Collections | Hacker News Reader

An In-Depth Look at Clojure Collections

infoq.com

39 pointsKototama14 comments

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)

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.

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.

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.

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

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.

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

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.

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

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

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.

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

Reply on news.ycombinator.com