in which the conjference is recapitulated

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.

Stuart Halloway on Simplicity

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.

Stop. Hammock Time.

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 than 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.

« older | 2010-10-31T05:15:28Z | newer »