On Dec 29, 2010, at 1:28 AM, Mark Engelberg wrote: > On Tue, Dec 28, 2010 at 10:15 PM, David Nolen <dnolen.li...@gmail.com> wrote: >> Even in in a single threaded context raw insert performance isn't the final >> word. What if you want to be able to deliver a snapshot for reporting? > > What if you don't? > > Seriously, I agree with you that Clojure's data structures have some > significant advantages -- if you need those advantages. There are > still plenty of apps that use hash tables in a single-threaded manner, > or use them in a multithreaded way where contention is unlikely and > persistence is unnecessary. In many areas, Clojure has a > pay-for-what-you-need philosophy -- this just isn't one of those > areas. With respect to data structures, Clojure is very opinionated, > with an attitude of "Write it with immutable data structures -- you'll > thank me later." :) Since all the existing Java structures are easy > enough to access if you want them, this isn't necessarily a bad thing. > It just means I have to rethink my proselytizing strategy -- I was > definitely overselling the speed of the persistent data structures.
Totally aside from the (valid) hint this offers for your advocacy efforts, I think this just a vote for "use the right tool for the job" -- a loaded statement that silently ropes in all sorts of premises associated with the local context and circumstances of the developers, business, and domain involved. I'd say that Clojure is opinionated in many different vectors; slipping portions of it into contexts where the developers in question insist on maintaining their current state of practice sounds like a particularly large windmill to tilt at. Clojure's facilities, taken individually, are interesting and maybe useful in limited circumstances. Persistent data structures have a lot of useful properties (for a price), laziness would seem to be a good solution to an incredibly niche problem, and reference types are an interesting take on the state/identity question; I submit that none of these on their own are particularly compelling. Use them in concert, however (assuming you've got first class functions, of course) and you have a cumulatively augmented result enabling you to do things you simply wouldn't be able to do before (or perhaps, wouldn't have considered possible before). From that context, those apps (or, really, those portions of some apps) that really benefit from using mutable data structures seem like a niche. Re: "if you need those advantages"... Personally, I think the most significant advantage persistent data structures offer hasn't been mentioned: the ability to program with values, and the elimination of errors and defects that arise from doing anything else. To answer your friend, *that's* why you should be willing to "pay that price all the time" (though only on assoc of course, and maybe not even there depending on the nature of the problem at hand and how much laziness/transients/pmap/etc can be brought to bear). I don't think that packaging up a hashmap-in-an-atom is really doing anyone any favors, at least if that particular animal is being called a "persistent data structure". FWIW, you might want to take a look at the FunctionalJava library (http://www.functionaljava.org/) for your friends that might be amenable to folding in some functional programming into their existing applications, but are strictly wedded to Java. It's opinionated in its own ways, but its pervasive use of generics may give some just enough of a handle on what's going on to grok what FP is about and why it's useful without going whole-hog and using a different language. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
