
Clojure Tradeoffs - puredanger
http://gtrak.wordpress.com/2013/06/26/clojure-tradeoffs/
======
plinkplonk
"Tradeoffs" implies a balanced look at the positives and negatives of each
design/engineering decision under discussion, and what is being traded off
against what.

This article is a paean to Clojure, a torrent of praise with little to no (or
very faint) criticism, and _has very little discussion of what is being traded
off for what_ , and what the positives _and negatives_ are, what the benefits
_and costs_ are, of each tradeoff.

The "Tradeoffs for Individuals" paragraph is a good example. Literally every
sentence of that paragraph is a variant of "Clojure is cool". There are no
'tradeoffs for individuals' actually discussed in that paragraph, inspite of
the title.

This is not to say Clojure isn't cool. It is. Rich Hickey has a great sense of
design and is a brilliant engineer. But an article titled "Clojure Tradeoffs"
should actually discuss, you know, tradeoffs.

Misleading title, but otherwise a decent article. A good alternative title
would be "Why I Think Clojure is a Great Language"

~~~
fiatmoney
I'll give a real tradeoff - persistent datastructures are much less efficient
to iterate through, since they usually involve a) returning "mutated" copies
at each iteration (not as bad as it sounds due to structural sharing, but much
more expensive than incrementing an index) and b) lots of pointer following &
manipulation.

Also, the STM has an interesting intersection with garbage collection
depending on your access patterns. Returning modified copies & throwing away
references to the old one, rather than mutating, can increase pressure on the
GC since you end up with more transient objects. Especially if you're
"mutating" objects that all end up living in the tenured generation.

~~~
kleiba
Why does the iteration have to return copies? Can it not just return the
object itself? Or are you talking about return-by-value versus return-by-
reference (Java does the latter)?

~~~
tel
Immutability means that if you're "modifying" the structure you must actually
be "making a new copy with a small change". Structural sharing means that
usually only the small change itself gets new allocation, but it's still more
pointer-chasing than a continuous memory map.

Lots of algorithms don't work with this kind of copying semantics, but you
have all of Purely Functional Data Structures [1] to help.

[1] [http://www.amazon.com/Purely-Functional-Structures-Chris-
Oka...](http://www.amazon.com/Purely-Functional-Structures-Chris-
Okasaki/dp/0521663504)

~~~
kleiba
Fair enough, but I wasn't talking about modification, I asked about iteration.

~~~
cgag
Just iterating doesn't make any copies. Replace iterating over with modifying.

Efficient immmutable data structures are easily one of Clojure best features.
Easiest trade off ever (though the actual hit to performance isn't that bad)
imo.

~~~
dragandj
Not only that, but you can also make a persistent structure locally transient
for the duration of the (modifying) iteration, so in lots of cases you do not
have to pay the persistence penalty.

------
jgrant27
This might be more useful (but a little dated) ... [http://lisp-univ-
etc.blogspot.com/2011/11/clojure-complexity...](http://lisp-univ-
etc.blogspot.com/2011/11/clojure-complexity.html)

~~~
gtrak
I think at least the criticism of immutability and FP resulted from taking
concepts to extremes. I made a point to address lock-in of different aspects
of clojure in my post.

I think if you're mutating deeply nested things, or doing heavy algorithmic
bookkeeping, it's worthwhile to evaluate different approaches (maybe pure
java) as an 80/20 thing, and I wonder how hard it would be to have comparable
mutability facilities and data structures as a library?

Of course, programmers want to get things done without spending time on
building up their own tools, and I understand that.

