

An In-Depth Look at Clojure Collections - Kototama
http://www.infoq.com/articles/in-depth-look-clojure-collections

======
gtani
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/>

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

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

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

