I found this post to be somewhat disappointing. It doesn't really have much depth to it and the claims have little backing. It's not that I don't believe the claims, they have been made before with evidence to support them, by other people. It's that I don't really see how this adds anything to the discussion.
I am not presenting breakthrough material here. I wrote this because there is still a lot of confusion about concurrency and people looking for hot new solutions without understanding the basic tradeoffs.
You have not done much to clarify the confusion, though.
The tone of your blog post indicates that absolute truth and universal advice is to follow — and then it doesn't. What I got from your blog post is that one needs to consider various concurrency primitives and solutions (duh) and that you used Java locking, Java frameworks and Hadoop, and haven't found much use for Clojure's STM. Well, good for you, but I guess people expected more from a blog post titled "Concurrency, State, and Functional Programming".
There are two aspects worth mentioning:
1) It doesn't matter how fast you get the wrong answer, so your concurrency approach had better be correct. This is much easier to achieve with Clojure STM than with manual locking and mutable data structures.
2) Cost/benefit ratio: assuming each concurrency approach gives you some benefits (usually execution speed is what you're after), what is the cost? Cost meaning your effort to write the code, debug it, test it, maintain it, document it, cost for others to understand it later?
For what it's worth, I am getting very good mileage out of Clojure's STM. For scaling on SMP machines it gets me good results with minimal effort. I get correct code (#1) and the cost/benefit ratio is excellent (#2).
>. This is much easier to achieve with Clojure STM than with manual locking and mutable data structures.
For easy stuff yes. For hard stuff that is such a grandiose claim to make, if you could do it with any certainty you would certainly be published. Personally, I don't think it's any easier.
Agreed. The author supports going outside of Clojure for larger scale processing, e.g. Hadoop. This is sensible, but it's some leap to call concurrency a fad.
It's likely that Clojure will target some other runtime (in the future). Concurrency primitives in Clojure (var, ref, atom, agent, future, promise etc.) are practical, elegant, and focused tools. Why work around them?
I am not calling concurrency a fad, I am calling the rush to try hot new concurrency primitives without understanding these basic tradeoffs a fad.
Clojure's concurrency primitives are just wrappers around the same java libs I mention in the post.
For locking, it just matters which code you depend on based on your need. If you need to deal with it yourself, using Clojure's STM is good, since Rich has done the work to wrap the locking. But if you just need a data structure with synchronized access, then you don't even need Clojure's STM. Similar arguments hold for Agents vs Executors.
I am not saying Clojure's concurrency primitives are bad, I am saying we need to understand the basics, and Clojure's primitves are not always necessary or the right solution.
> I am not saying Clojure's concurrency primitives are bad, I am saying we need to understand the basics, and Clojure's primitves are not always necessary or the right solution.
Your post seemed very light on actually discussing this point, which I think would have been appreciated. There are always a lot of trade-offs to be made in writing concurrent code. The shallowness of your post left me wondering why you made some of your choices, or if you even thought particularly hard about them.
Not using transactions effectively forces anyone who wants to call into your code to also not use transactions, or they'll be bitten by the retry behavior.
This may not apply to your library (it seems like maybe it only calls code, rather than being called by it), but the approach you're suggesting can greatly reduce the utility of a library for other people if you're not careful.
I didn't like this at all. I found the one-sentence format distracting and the article lacking a theme. It read more like a laundry list directly out of somebody's brain. What a strange style for an essay.
I'm probably still ouching from watching it tank on the "new" page. Very sad experience, that. :)
It just doesn't seem like there is much here. Certainly not enough to warrant the votes it's getting. I must be missing something, because between the odd style and the lack of substance it doesn't seem to match up to the response from the community.
Perhaps this piece has a more engaging title than yours? It also has pictures. That makes the page nicer too look at--even if it would just be Sashimi and bore no relation to your content. Often it's also luck, whether your article makes it to the front page.
If you want to try again, just post your article under a different URL and re-submit at another time.
I guess if you do not do it too often, nobody will have anything against this practice. If you want to be ethical, just do a some work on your article, between each submit.
Nearly every piece can profit from rewriting anyway. Just as a suggestion, have a look at Haskell's QuickCheck and see how it applies to your argument. There's also a nice blog post about rolling your own window manager (http://donsbot.wordpress.com/2007/05/17/roll-your-own-window...), that emphasizes using the right data structures to statically guarantee your invariants with the help of the compiler where possible instead of writing tests.
(excuse the meta) Nyah. It's not a big deal either way. What's so interesting/frustrating about the process is the degree of randomness involved. You spend five hours writing a story on something you think important and insightful, it tanks. You spend 30 minutes on a vapid rant, gets voted to the top. Go figure.
What I think it boils down to is emotional impact instead of writing quality or topic. Articles, titles and authors that have the greatest emotional impact in with the audience during the first 45 minutes or so (the time it takes to sink off the new page) do well. Others not so much.
An interesting "feature" of the voting system is that stories that get voted up a lot in the first part of a 3-hour period stay on front longer than stories with similar vote counts that all occurred at the end of the 3-hour period. The number of people that like it isn't germane -- it's the degree of swiftness with which the upvotes occur. That means that if your article is a hit with 20 folks in the community, you'd better know that those 20 folks are online if you want others to see it. Little things like this probably lead to voting-ring-like behavior on the part of users. I know it certainly can be frustrating.
