Software Engineering at Prismatic
blog.getprismatic.com
blog.getprismatic.com
I wrote a web crawler in clojure at at&t and our team came to this same conclusion. First we tried to implement a custom atom, but finally using java.util.concurrent directly.
I'm not sure what this says about the clojure concurrency features, but I've found myself using them sparingly even when doing a lot of concurrency.
Fact remains that STMs (as originally developed by the Scala team in (yes) Java), "outstanding" [OP] concurrency, and idempotent/functional programming remains /well within reach/ of the seasoned developer in Java.
Also, unless I misunderstand their architecture (and it is single node ..), then the fact remains that in a distributed system, the "semantics" of interaction are not bound by the programming language behind box x, and are entirely a matter of the (remote) API you expose. STMs are a concern of a shared memory space -- once you go distributed, it is really borderline snakeoil to talk about the benefits of "functional" languages in creating remote functions.
Our use case was fairly odd though.
Wow, I couldn't agree more with this concept of library vs. framework. While frameworks provide all kinds of up-front time savings, I've never used one that didn't end up getting in my way and require all kinds of deeply placed hacks to work how I (or my company/client) wanted.
I sometimes feel out of the loop because I'm not using all of the popular frameworks everyone else is talking about at the moment. So it's refreshing to hear I'm not alone in the opinion that time is saved in the long run by writing one's own small, modular, easily understood and reused libraries if none are already available.
I do feel as though small, self-contained code bases are becoming easier to find with the rise in popularity of sites such as GitHub and Bitbucket. So perhaps the trend towards less monolithic software can become more mainstream.
http://web.archive.org/web/20101102120728/http://measuringme...