Have you ever tried to log from a multi-threaded program? Have you tried to make sense of log output when multiple subsystems were logging to it? Have you tried to do average latency calculations based on that log file?

If you’re reading this blog, I’m guessing you answered yes to a couple of the questions above.

There are multiple problems here: multiple producers (race conditions), out-of-order logs, conflated subsystems in the same logs, etc. You have to put a lot of effort into your log post-processor to make any sense of the data, decorating it with various metadata to make it possible at all.

Here’s another post on a topic that has been discussed since the dawn-of-time: is there a nice and idiomatic way to write Erlang/Actor-style distributed programs in Clojure? There have certainly been a few attempts, but Rich’s post (above) still holds true today.

First, some clarification: I am not primarily thinking about number-crunching, map/reduce-style stuff, where Clojure has a pretty good story:

• clojure-hadoop
• swarmiji
• cascalog
• zookeeper-clj
• storm
• etc.

Akka and the Erlang legacy

I am trying to write programs that solve problems in the areas where Erlang typically excels, such as:

Software is different from most other things humans build, hence companies creating/selling/licensing software must be different from other ‘production’ companies as well? Some definitely are but the vast majority are still trying to apply old civil engineering practices to software development. Why are they wasting so much time and money on upfront sizing, planning and tracking when all empirical evidence tells us it maps so badly to the actual process of developing software? Why haven’t most software companies learnt the hard lessons and started to operate like Valve?

A couple of weeks have passed since I pushed Frinj to github and blogged/tweeted about it. The response has been pretty awesome, one highlight being when @stuarthalloway showed me a frinj+datomic example gist on the #datomic IRC channel. In short, the Clojure community is #badass.

Frinj comes with a big database of units and conversion factors, and while many conversion factors are “eternal”, others aren’t. Exchange rates, for instance, have to be kept up to date to be relevant. The Frinj unit database was designed to be updatable, both for usability when doing various calculations and for rates that constantly change. This is the reason the frinj.calc namespace exposes the (frinj-init!) function to reset the unit database to a known baseline (in case you write over some factors, etc.). Clojure’s support for atomically updating state is ideal for this purpose; the calculator’s state is kept in a number of refs and, thanks to the STM, always kept consistent.

I am proud to announce a new Clojure project called “Frinj”.

Frinj is a practical unit-of-measure calculator DSL for Clojure.

Key features:

• Tracks units of measure through all calculations allowing you to mix units of measure transparently
• Comes with a huge database of units and conversion factors
• Inspired by the Frink project
• Tries to combine Frink’s fluent calculation style with idiomatic Clojure

Full source code available on github.

To whet your appetite, head straight over to the sample calculations page to see what Frinj can do!

Edit: This post recently re-surfaced on hacker news and caused a bit of a stir, mainly because of a slightly sensational/misleading title (was “Why is Clojure so slow?”). I wrote this before Rich Hickey’s Clojure/Conj 2011 keynote was published, in which he talks about most of my concerns (and outlines possible solutions).

Clojure is great in many ways, but one thing it can’t be accused of is being particularly fast. What I mean by fast here is the speed at which Clojure programs execute. This is a well-known issue in the Clojure community and has been discussed on the mailing list and Stack Overflow.

This is a follow-up post to my previous “Scheme in Clojure” post.

This time we implement a Scheme interpreter as an external DSL. This means that we consider the DSL as completely foreign to the host language, so we need to write our own parser (or reader as it’s called in Clojure) and interpreter. I have to admit that this is a bit of an academic exercise because the internal DSL version I wrote about previously is both smaller (less code) and faster (as fast as any other Clojure code). However, this can serve as an example of how to write parsers in Clojure and it also highlights how elegant and succinct such a parser/interpreter can be. And of course, it’s pretty darn fun :-)

Asynchronous workflows is a very powerful feature of F#, and recently I wanted to explore the state of the JVM and in particular Clojure when it comes to replicate the functionality. In this post I’ll share some of my findings and I’ll include some background material to explain the problems.

Let’s start with an example of a webclient using “async” in F#.

let download url = async {
  let request = HttpWebRequest.Create(Uri(url))
  let! response = request.AsyncGetResponse()
  use stream = response.GetResponseStream()
  let! res = asyncReadToEnd stream
  return res
}

The magic here is that you can write continuation-style code in a sequential manner. This combines the scalability of asynchronous programs with the readability of sequential code. So, what lessons can we learn from this code and how would we do this with the JVM and Clojure? First of all, this is not the same as using futures over blocking calls;