I got back last night from a week in BAMA for the Clojure Conj conference. The consistent quality of the talks surpassed any other conference I've attended so far, and there was a palpable high-energy air of potential with so many focused hackers congregating for the first time. The only downside was that the breakneck pace of fitting all the talks into two days left little time for ad-hoc chatter and hackfests, something I've greatly enjoyed at Ruby conferences.
I got a chance to speak on Leiningen. [slides] I opened with basic usage followed by a few little-known but useful features. After that I took some time to explain how Leiningen tasks are written and extended. I spent a little more time on this since it's something that folks have asked about recently. The gist I tried to get across is that it's best to structure core concepts like tasks around functions rather than one-off mechanisms like macros or custom deftypes if at all possible as it encourages composability and is instantly recognizable to users at a glance.
It turned out the emphasis on functions in order to support composability was a common theme that everyone seemed to come back around to, most notably Mark McGranahan on Ring and Stuart Halloway on simplicity in general.
Near the end of the conference Rich gave a self-professed non-technical rant on the simple subject of thinking hard about hard problems. He said that one of the things he's most thankful of in his life is the opportunity to spend years thinking about a few problems. The idea that you could think about a hard problem for months on end, in what he termed "hammock time", is something most people (myself included) just hadn't ever considered.
When I met him after the Emerging Languages
conference earlier this year, he mentioned how the notion of
linear version numbers no longer meshes with the reality of
distributed development. On
Clojars there's a notion of
non-canonical versions being distributed under a separate group,
which makes Maven unable to weed out duplicates. But if they were
kept under the same group, it would have to use version numbers to
distinguish between the official version and the patched
one-offs. Even in a non-forked project you have branches from
which you may wish to publish artifacts. Being linear, version
numbers are really not well-suited for this. They are
lexographically sorted, which means there's no way to denote that
1.3.0-alpha3 may be newer
1.3.0-par2. Dependency management needs to
accept the fact that versions branch into trees. But representing
it as such is really only the first step; the other tricky part is
coming up with a strategy to choose a branch and how to decide
between different dependencies that both may request different
branches of a third dependency. It's a juicy problem that was also
mentioned a few times at the Conj, and it may be the kind of
"hammock time" problem to keep in the back of my mind for a few
months or years.