Technomancy

in which a turtle moves things forward

2013-05-15T18:09:44Z

Recently on the Clojure mailing list someone started an interesting thread on what motivates you as a programmer. My friend Nelson Morris responded as so:

Contributions and projects start off well, and energy might wane depending on time and life factors. Even contributing to tools used by many of the members of the community like [Leiningen] and Clojars doesn't prevent it. What helps is direct involvement by someone else.

This really resonated with me because it emphasizes that people are more important than programs. For me sharing is the thing that makes programming even worth doing in the first place. So it got me thinking about different technologies and what kind of people they're good for helping.

If you follow my writing it will be obvious that I enjoy working in Emacs and Clojure. While these are among the most powerful, flexible technologies I know of, collaborating with others on tools for Emacs and Clojure basically limits me to working with professional programmers, because both environments are very poor from a beginner's perspective. If I'm working solo or on a team of seasoned hackers, I'll definitely be most effective with Clojure. If my primary goal is to interact with the widest group of programmers possible, I would use Ruby as it's the most commonly-used language I can bring myself to use. But if I want to reach out to people who don't already spend all day thinking about functions and data structures, well that's another thing entirely.

This is particularly relevant for me personally as a father. I'm taking an active role in the education of my sons, and of course I think technical literacy must be an important part of it. But when you look at how computers used in traditional educational settings, you're much more likely to see computers programming children than children programming computers. So I've been looking for ways to foster technical skills and encourage algorithmic thinking in engaging ways that can keep the attention of my five-year-old.

In the book Mindstorms, Seymour Papert describes the shift from concrete reasoning to formal reasoning as one of the main transitions children undergo as they learn to think like adults. One of the design goals of the Logo system he created was to provide transitional concepts to bridge the gap between the two.

Children interact with Logo by giving commands to an onscreen object known as the turtle. While the turtle lives in the abstract world of geometry comprised of points and lines, children are able to identify with it since they tell it to move in ways which they can relate to—it has a heading and position, and it turns and moves forward and backwards just like they do. Because the turtle's movements on the screen are isomorphic to their own physical movements, it gives them a model to help them grasp abstract geometrical concepts though they're only used to thinking in concrete terms. And Piagetian learning—ambient, natural learning which children are so adept at doing without study—is all a matter of building models of the world.

Most people know Logo from its original triangle-turtle-centric incarnation, but in Mindstorms Papert describes Logo as more of an educational philosophy than any single program, language, or implementation. A more recent version of Logo is Scratch, a drag-and-drop visual programming environment from MIT's Media Lab targeting school children. Since my older son is an early reader he's been able to construct simple scripts (with some guidance) for the characters within Scratch, watching them interact with each other and even in some cases the outside world.

While it's been lots of fun to come up with ideas and talk through how we'd bring them to life on the screen, one of the most rewarding parts is watching his problem-solving abilities develop. Papert talks about how children are often afraid to try things for fear of failure, but Scratch teaches that debugging is a normal part of making things work. Rather than "does it work", the question becomes "how can we make it work?" This was demonstrated the other day (outside the context of Scratch) when he was putting together some Snap Circuits:

Of course the goal is not to produce "little programmers". It's primarily about developing the ability to think systematically, but it extends beyond that into getting them thinking about thinking itself. In some sense once they're in the habit of asking the right epistemological questions, the parent or teacher almost just needs to get out of the way and let them explore. At that point the process of discovering a topic with someone is much more rewarding than telling facts at them.

in which everything is ephemeral

2013-04-12T08:56:45Z

There's been enough written about the benefits of remote work that I'm not sure I can add much to it beyond anecdotes. From my own experience I've been a remote worker for all but a year and a half of my career and have loved it. The amount of time wasted by cars commuting is sobering, and the ability to start the day after simply crossing my back yard to the code lab is not something I'd give up lightly. Especially with warmer weather coming up in Seattle the draw of working outdoors and at various coffee shops is strong indeed.

But the thing about remote work is that it can be really difficult to do effectively. At my last job we were dedicated from the outset to making the fully-remote model work, and we were able to assemble a team that functioned fantastically well while drawing from talent all over the country. But in order to make this work we had to set things up so that no one operated in isolation. We had our daily stand-ups, but more important was spending the bulk of the time paired with another hacker over SSH and VoIP. And even when not paired, there was the understanding that you could easily grab someone to get a real-time review of whatever you were writing.

In order to facilitate this, we would usually set up a shared user on each laptop (or sometimes on an unused server sitting under a desk somewhere) and do the necessary port forwarding wrangling and public key management to ensure others could SSH in and join our tmux sessions. Given that it was something we relied on every day it wasn't particularly onerous to set things up, and over time the tools got a bit better. (Vagrant to manage pairing VMs, a common repository for the team's pubkeys, etc.)

These days things are different—I'm at a company that embraces a remote/local mix of teams rather than being fully remote. While I've got co-workers who are happy to discuss and review code remotely, I can't assume everyone has spent the time to to facilitate remote collaboration if it's not an everyday tool for them. And when you're looking for another set of eyes on a problem, you need frictionless tools; otherwise you might not even bother asking for help. So I put together Syme.

Syme sets up disposable EC2 hosts for collaborating on GitHub projects via ssh and tmux. The idea came from a fantastic site called pair.io, which has since unfortunately fallen into disrepair. (There's a great video on their splash page explaining things if you've got a couple minutes.) Basically you give it the name of a project you want to hack on and who you want to hack on it with, and it can preconfigure the host by checking out a copy, adding SSH public keys for all invited users, and running all the necessary setup scripts to get dependencies and user settings installed. Then everyone just SSHes into the machine and joins a shared tmux session, and it's all yours.

I had access to the private alpha of pair.io, but since billing hadn't been implemented yet I always felt a bit guilty whenever I launched a machine to work on since it would just rack up the hours in the author's Amazon account.

I'd been thinking what it would take to implement that kind of thing myself but had been dissuaded by the idea of writing a billing system. Whenever you're dealing with money on behalf of the user it can hardly be considered a for-fun project. But then I realized that can be neatly sidestepped simply by prompting for the user's AWS credentials while launching the instances. It turns out keeping those around in an encrypted cookie in the browser makes it possible to perform further operations on the user's behalf without getting into the harrowing business of storing secrets. It also means it can be done completely as free software, and it's not tied to myself at all—if I lose interest and wander off anyone else can pick it up and deploy on their own.

So I've gotten it to the point where I'm pretty happy with it. At just a shade over 500 lines of Clojure it's quite tidy. I'm hoping it comes in handy streamlining things at work, but it's open for any remote collaborators who may find it useful in any kind of pairing contexts. If you run into any issues trying it out or have suggestions, please head over to the GitHub issue tracker and let me know.

in which we cater to those with an allergic reaction to parentheses

2013-04-01T20:42:59Z

A lot of people have been talking about how parentheses are such a big barrier to adoption of Clojure these days. Apparently they're pretty intimidating when you're used to a language with a lot of curly braces and things. While I can't do anything about Clojure itself, I realized we could make some changes to Leiningen that would allow newcomers to return to the comfort of XML. My latest plugin is called lein-xml, and it lets you write this:

<?xml version="1.0" encoding="UTF-8"?>
<project>
  <groupId>org.leiningen</groupId>
  <artifactId>sample</artifactId>
  <version>0.1.0-SNAPSHOT</version>
  <description>Just some kind of sample thing</description>
  <url>https://github.com/technomancy/lein-xml</url>
  <licenses>
    <license>
      <name>Eclipse Public License</name>
      <url>http://www.eclipse.org/legal/epl-v10.html</url>
    </license>
  </licenses>
  <dependencies>
    <dependency>
      <groupId>org.clojure</groupId>
      <artifactId>clojure</artifactId>
      <version>1.5.1</version>
    </dependency>
    <dependency>
      <groupId>slamhound</groupId>
      <artifactId>slamhound</artifactId>
      <version>1.3.3</version>
    </dependency>
  </dependencies>
</project>

...instead of this bewildering, unfamiliar invocation:

(defproject org.leiningen/sample "0.1.0-SNAPSHOT"
  :description "Just some kind of sample thing"
  :url "https://github.com/technomancy/lein-xml"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.5.1"]
                 [slamhound "1.3.3"]])

I know it probably won't be used by anyone who has spent much time with Clojure, but for newcomers hopefully this will remove one of the big blockers for enterprise developers trying out Clojure.

in which laziness mostly predominates

2012-09-26T15:41:26Z

The last few days have been a whirlwind with the fantastic StrangeLoop conference, such that I forgot to mention that my interview with Chas Emerick of the Mostly Lazy podcast was posted recently. In it we rant about user-serviceable hardware, my recent reading list, extensible systems, the latest developments in Leiningen, and more.

in which we retire a workhorse

2012-08-22T05:50:47Z

When I first got started with Clojure I was disappointed that the process of getting started was pretty rough around the edges, but one of the things that helped sustain my momentum was the fact that I could use SLIME to write Clojure code from Emacs via the swank-clojure project, running and testing it while in the middle of writing it. This helped me overlook the fact that I needed to construct nasty java command-line invocations to launch the process.

As time went on I did what I could to try to improve the situation. Early attempts were quite primitive, but eventually when Leiningen came out the lein swank command obsoleted all my hokey elisp setup scripting. Still a few other things kept it from being a really smooth experience. The main issue is that SLIME was developed primarily for Common Lisp. The protocol behind it changes every so often, and there aren't any stable releases; users are expected to simply run straight out of CVS.

When the creator of swank-clojure passed maintainership to me, I kept things going by applying patches and adding a handful of features at the edges, but nobody really understood the ins and outs of the project. Part of this was because it was just a really old quirky codebase, (most of it predated the introduction of Clojure atoms) but part of it was because it was a fairly literal port of the Common Lisp server.

The end result was that SLIME moved forward while swank-clojure stood still. This mostly worked once we bundled a frozen SLIME revision, but it was common to have confused users wander into the IRC channel with a broken setup, unsure of where it went wrong or how to get the right SLIME. Even for experienced users it was impossible to have a setup that could connect to both Clojure and Common Lisp at the same time.

Meanwhile in Clojure-land the nREPL project was started as a tool-agnostic counterpart to swank-clojure, building a general networked repl server and an ecosystem around it. While I appreciated the idea, I thought that it would be a long time before Emacs support for it could catch up to the level of functionality in SLIME.

Still, one evening on a short flight to San Francisco I bashed out the beginnings of an nREPL client in Emacs. I got a bit stuck on the socket-based bencode functionality and dropped it after the flight, but not before pushing the code out and mentioning it on the Clojure mailing list.

Fortunately Tim King picked it back up, and now it has quickly become a respectable competitor to SLIME. I've switched over to it for day-to-day use. The main thing I've noticed about it is how accessible the codebase is; I've found it very easy to dive in and add features. So even though it's still missing a few things that SLIME boasts, it's on course to improve at a steady pace. It also works out of the box with Leiningen 2.x's repl task without any extra plugin needed.

It's now gotten to the point where I'm ready to consider swank-clojure deprecated. Of course, it will go on working, so if you already have a setup that works for you, there's no need to switch. Also if you find yourself particularly attached to the inspector or debugger from SLIME you might want to hold off. (For debugging in particular the ritz project works with SLIME and has advanced debugging features.) But if you're looking for a simpler way to get started, give nrepl.el a try.

Update: Jeffrey Chu, original author of swank-clojure, writes: As creator of swank-clojure, I'm a little sad to see it die. But I'm very happy to see that it's being replaced by something designed/maintainable instead of hacked about just to scratch an itch. Thanks for keeping it alive all this time and I look forward to the great work coming out of nrepl.el.

in which the facts are laid out concerning swarm coding

2012-07-01T04:43:18Z

I've found that user groups often fall into a pattern of lecture style presentations with slide shows. Since it's usually difficult to find presenters, often it ends up that after a while whoever founded the group speaks repeatedly. This leads to burn-out and isn't sustainable even if you're fortunate enough to have presenters who are skilled public speakers. It's also simply not a very good way to learn; your mind is a lot more involved in a when engaged in active discussion.

This is why at the Seattle Clojure group we follow a different model that focuses on code and participation. A few months ago at the ClojureWest conference I gave a short talk (PDF) explaining the motivation behind this style. I call it "swarm coding".

The Socratic Method is a form of learning that centers around getting people to ask the right questions rather than just telling. It's often used in group settings with classical education methods, and I've found it's a great way to run a user group meeting as well. If you can get everyone hooked in to participate in a shared editor session and come up with an idea for a small project, you can collaborate in a unique, engaging way and learn a lot.

We've found SSH, tmux, and Emacs to be a great combination for this. The host prepares his machine with a new user created just for the purpose of swarming, and everyone is given the username, hostname, and password to log in over SSH.

$ ssh swarm@zuse.local
$ tmux attach

Once logged in, running tmux attach allows a user to join an in-process session started by the host, and control can be passed around as discussion progresses. If someone has an idea for how to address a certain problem, they can just try it out straight away. While there are more complicated setups that can allow for each user to edit independently, we've found that is usually not what you want. If you have a discussion going on, you want a single point to focus on. It's really hard to track what's happening if you have multiple independent edits happening simultaneously.

Usually skill levels vary widely in group settings like this, so it's important for the facilitator to be able to gauge them, usually by just getting quick introductions from everyone in the group beforehand. The temptation is often for those that really know their way around to just power through and write some slick code, perhaps pausing to explain a particularly subtle technique. It's more rewarding to let control pass around the group and try to keep everyone involved, but it can be difficult.

It's probably a good idea to dedicate a meeting to a tooling workshop at first to get people started. Especially with Clojure the initial setup can be intimidating, so the newcomers find it valuable to get help just getting the basics working on their laptops. While I don't recommend newcomers try to learn Emacs as their main editor at the same time as picking up a new language, it really makes collaboration over SSH much easier, so basic familiarity is helpful.

I've coded up some scripts to automate setup of swarming sessions. It handles getting basic dotfiles in place and provides instructions for how to join a session when people log in. Right now it only supports Clojure, Leiningen, and Emacs, but there's no reason it couldn't be extended for Vim or other languages.

Update: I have another project called Syme which handles setting up pair/swarm nodes on EC2. In most cases this is a lot simpler than running the tmux session on your own machine, though it may not always be feasible depending on the quality of the network.

There are a few things to watch for here. First of all, we've only tried this with groups of up to 12 participants. Group dynamics break down when things get larger, so you may want to split up into groups. You could try splitting a project into independent parts that could be coded by each group if your project divides naturally this way, or you could try both tackling the same problem and comparing solutions at the end.

Picking a project to try is also tricky. You want it to be somewhat useful and not contrived, but you also need it to match the skill level of the group and still be able to make progress on it in a couple hours. It's a lot of fun if you end up with a project you can publish to Clojars or Heroku at the end.

Happy Hacking!

in which three programming methods are compared

2012-05-16T16:07:43Z

There are, roughly speaking, three ways to develop large user-facing programs, which we will refer to here as 0) the Unix way, 1) the Emacs way, and 2) the wrong way.

The Unix way has been expounded upon at length many times. It consists of many small programs which communicate by sending text over pipes or using the occasional signal. If you can get away with using this model, the simplicity and universality it offers is very compelling. You hook into a rich ecosystem of text-based processes with a long history of well-understood conventions. Anyone can tie into it with programs written in any language. But it's not well-suited for everything: sometimes the requirement of keeping each part of the system in its own process is too high a price to pay, and sometimes circumstances require a richer communication channel than just a stream of text.

This is where the Emacs way shines. A small core written in a low-level language implements a higher-level language in which most of the rest of the program is implemented. Not only does the higher-level language ease the development of the trickier parts of the program, but it also makes it much easier to implement a good extension system since extensions are placed on even ground with the original program itself. I wrote about this in an earlier post on the live-development model Emacs offers:

If you have to use some tacked-on "plugin mechanism" to customize it, then you’re going to be limited at the very least by the imagination of the author of the plugin mechanism; only the things he thought you would want to do with it are doable. But if you’re using the exact same tools as the original authors were using to write the program in the first place, you can bet they put all their effort into making that a seamless, powerful experience, and you'll be able to access things on an entirely new level.

-in which a subject is attempted to be approached objectively, though such a thing is actually impossible

It's worth noting that this is the model under which Mozilla is developed. The core Mozilla platform is implemented mostly in a gnarly mash of C++, but applications like Firefox and Conkeror are primarily written in JavaScript, as are extensions. Following the Emacs way accounted for Firefox's continuing popularity even back when it was getting trounced by competitors in terms of JavaScript performance. Chrome's extension mechanism is laughably simplistic in comparison.

Finally for completeness sake, the wrong way is simply to write a large monolithic application in a low-level language, usually C++. Often half-hearted attempts at extension mechanisms are bolted on to programs developed this way, (usually in order to check off another box on a features list) but they are invariably frustrating and primitive and don't end up offering extension developers the same access to program internals that the developers of the original program itself have.

The Unix way makes particularly explicit the notion of composing small programs, but the Emacs way shines when a single runtime process plays host to a number of independent programs that can interact with each other gracefully. For instance, the Magit version control interface can run in the same Emacs instance as a SLIME session controlling a lisp project. They coexist in a complimentary way and compose together without interference. So rather than saying there are three ways to write large user-facing programs, it might be more accurate to say that there are zero good ways to write large user-facing programs and two ways to compose a number of small programs into a coherent system.

This is especially interesting to me right now since it has come to my attention that when it was rewritten in the transition from version 2 to version 3, GNOME has switched to the second way via an embedded JavaScript runtime, which means things are about to get very interesting.

in which korean hardware pleases

2012-05-09T04:25:14Z

I just got a new laptop, and while I wouldn't post about it normally I've had a number of people ask me what I thought of it. For the last five years or so I've been a Thinkpad user exclusively, but the latest models of their lightweight X series have offered disappointing screens with 1366x786 being the only resolution option. Since my dignity prevents me from buying a laptop with fewer vertical pixels than my phone, I broadened my search this time around and came across the 13-inch Samsung Series 9, aka NP900X3B.

Update August 2012: I've gone back to the old Thinkpad after getting it repaired. I realized after a month or so with the Samsung that the ultra-thin profile is actually an anti-feature. I like my laptops small, but I realized that weight is really the only thing I care about in that category. There are no concrete benefits to be had from a thin design, while fact that it forces a shallow, uncomfortable keyboard, inaccessible battery, less-sturdy chassis, and hard-wired SSD are very tangible drawbacks. I definitely do miss the brilliant screen, but I'm glad to be on a machine that doesn't sacrifice functionality for looks. If you're considering a Series 9, I'd still say it's better than most laptops on the market. If you're coming from a Macbook, the keyboard and inaccessible battery might not bother you, but I'd encourage you to take a look at the Thinkpad X series too.

At first the most striking thing about it is its thin profile, but once you've started using it you realize it's the screen that really sets it apart. Samsung is the largest manufacturer of LCDs in the world, so it makes sense that the screen would be the distinguishing factor on their high-end models. The resolution is 1600x900, which I couldn't find in anything else smaller than 14 inches, but it's the 400 cd/m² of brightness that really sets it apart. With summer right around the corner, this perfect for working outdoors.

While I'm pretty thrilled with the new machine, the thin profile forces some difficult compromises with the keyboard. It's of the standard chicklet design, which is a drag coming from the Thinkpad. The X200s Thinkpad I was using previously had a very comfortable response and depth to it that you don't find with most chicklet keyboards. The Samsung also lacks a trackpoint, drainage tray, and dedicated volume buttons. The X200s isn't appreciably heavier than the Samsung; (only ½ a pound more) but it is over twice as thick. Personally if it's light enough I don't find thickness to be a problem; I'd much rather have a comfortable keyboard than a 0.4-inch profile. But it does turn heads.

The speakers on ultraportable laptops like the X200s typically come across as a token effort to fill a feature checkbox, but the Samsung's are fairly respectable. I was pleased to see the lack of the hardware wifi kill switch that plagued me on my Thinkpad. It's also got a bigger selection of ports than you'd expect with the slim profile: USB 2, USB 3, micro-HDMI, combined mic/headphones, and Ethernet, though the latter must be used with the provided adapter.

I'm running Debian Wheezy on it because I read on a blog post that a newer kernel was needed for the wifi drivers, but apparently this was only the case with an earlier model of the Series 9 that used the Broadcom chipset; The NP900X3B uses an Intel chipset that has been well-supported for some time. Everything worked perfectly out of the box except the keys for adjusting the keyboard backlight. The camera, external monitor port, and multitouch trackpad work as you'd expect. The suspend functionality, which on Linux has traditionally lagged behind Mac OS X, resumes in a couple short seconds.

While I would love to see this same screen on a laptop with the luxurious keyboard, carbon fiber body, and replaceable battery of a Thinkpad, the Series 9 is quite slick and should keep me happy for a number of years.

in which we plot an escape from the quagmire of equality

2012-04-27T05:45:01Z

If you follow happenings in the Clojure world, you may have noticed that the announcement of clojure-py brings the number of runtimes targeted by Clojure up to four. While it's great to see the language expand beyond the JVM, it's not too exciting to me personally since the runtime I spend the most time in by far is that of Emacs. Of course, Emacs can already be programmed with lisp, but the dialect it uses leaves much to be desired. I miss first-class functions[1], destructuring, literals for associative data, and immutability whenever I find myself writing nontrivial Emacs Lisp code, and the lack of these features makes me reluctant to write in it even though it offers an environment with live feedback unmatched by anything but the Smalltalk images and Lisp Machines of yore.

Part of what makes ClojureScript interesting is that it has distilled the number of primitives needed to port Clojure to a new runtime down to a small number due to its push towards self-hosting. One of the Summer of Code projects for this year is to allow for pluggable backends in the ClojureScript compiler, with Lua as a proof of concept. I started to think through what would be necessary for this to happen on the Emacs runtime, but I ran into an interesting quandary regarding referential transparency.

A function is referentially transparent when it is guaranteed to return the same value every time it is called with a given set of arguments. This is a great guarantee to be able to make about your functions as it reduces the number of things you need to keep in your head. Referentially transparent functions really can be thought of as black boxes: always deterministic and predictable. But a function that operates on mutable objects cannot be referentially transparent—it cannot make any guarantees that future calls involving that same object will result in the same value since that object could have a different value at any time.

Since Emacs Lisp does not provide any immutable data types other than numbers, only functions that operate on numbers alone can be referentially transparent. This is a shame, since referential transparency allows you to have much greater confidence that your code is correct. Without it, the best you can say is "as long as the rest of this program behaves itself, this function should work". This works a lot like older OSes with cooperative multitasking and no process memory isolation, which is to say not very well.

But arguably the worst thing about lacking referential transparency is that you can't check for equality in a meaningful way. Henry Baker's paper "Equal Rights for Functional Objects" addresses the problem of equality in Common Lisp[2], which is notable for having a plethora of equality predicates depending on what level of coarseness you want:

EQ: are both arguments the same object in memory?
EQL: like EQ, but compares value for non-immediate numbers like tagged fixnums and bignums.
EQUAL: do both arguments have the same structure and contents?
EQUALP: like EQUAL, but allows integers to equal floats and ignores string case.
=: are both numbers of equal value?
CHAR=, STRING=, STRING-EQUAL, ad nauseum.

Baker argues that this confusion is due to a muddled notion of object identity. Everything would be so much simpler if we could think in terms of operational equivalence:

Two objects are "operationally equivalent" if and only if there is no way that they can be distinguished, using ... primitives other than [equality primitives].[RNRS]

Asking "Are these two objects stored in the same memory location?" lets implementation details leak into your code. Equality should really be about "Can these two objects behave differently in any observable way?". Baker's paper implements the egal function in terms of this question; it's an equality predicate that defines object identity as a transitive closure of immutable attributes of an object. So without immutability, egal can't do any better than eq.

Of course, with a compiler that targets Emacs Lisp, you can work around this by implementing your own immutable types. But this makes any form of interop much more cumbersome; close integration with its host platform is one of the core design tenets of Clojure, and having to perform conversions on basic types like strings just to call native elisp functions would be too cumbersome to be practical. So with the Emacs runtime as it is, you have to choose between getting equality right and seamless interop. Damned if you do; damned if you don't.

There are two possible solutions to this. There has been an ongoing effort to get Emacs Lisp running on the Guile VM. As it comes from a Scheme background, Guile provides the immutable data types we need. (Update: the immutable types offered in Guile do not actually come from the Scheme standard, but they are present nonetheless.) However, Emacs Lisp is very different from Scheme, and the Guile implementors have an enormous task ahead of them to get even the basics working; the amount of work needed to achieve compatibility with the bulk of quirky extant Emacs Lisp code is daunting. But it would be wonderful if it were possible.

The more realistic option is to add immutable data types to the existing Emacs implementation. I suggested in passing on the emacs-devel mailing list that I would be interested in financially supporting such a feature, which led to a discussion of its pros and cons. It turns out there is very little code that would break if Emacs strings became immutable; even though it's possible to change strings it happens rarely enough in real code to not pose serious problems. Changing lists to be immutable would break huge amounts of code though, so a more reasonable approach would be to offer an alternate list constructor for immutable lists so that functional code could have access to immutability without wreaking havoc on existing functionality. Ideally libraries could opt-in to having the reader return immutable lists, but I don't know enough about Emacs's reader to know how feasible this is.

Unfortunately I'm not the one calling the shots; I don't have the C skills necessary to make it happen even if the Emacs maintainers were favourable to the idea. But it's interesting to think about, especially as concurrency may be introduced in Emacs 25. One certainly can dream.

[1] Common Lisp fans claim that lisp-2s have first-class functions, but the way they are kept separate from other first-class values in their own namespace ghetto brings to mind claims of "separate but equal"—at best it is Jim Crow functional programming.

[2] Emacs Lisp is not Common Lisp, but the two dialects are very closely related, and for the purposes of this post share the same problems.

in which we coin a term which is the opposite of deprecate

2012-02-29T00:57:50Z

Earlier this month I published the results of a survey I had posted for Leiningen users. I got a lot of great data, but I especially appreciated the free-form "other comments" section that let people just ramble. I was happy to see that many of the suggestions have already been implemented in the ongoing work on Leiningen 2.

I still think lein-multi should be rolled into core so people can be encouraged to test cross-version.

Profiles

This brings me to what is probably the biggest feature in Leiningen 2.0: profiles. In Leiningen 1 we had some special cases to segregate out "dev" mode from the rest so you would only have certain dependencies or directories available during development. This is useful to have, but the implementation was pretty ad-hoc and riddled with special cases. During some discussion with the Cake developers we talked about whether that could be generalized, which turned into the idea of profiles.

So now rather than a handful of project configuration keys that are only active during development time, we have a :dev profile that's active by default where you can keep your additional test-only :dependencies and :resource-paths. You can also keep all your :plugins that you want active across all projects in the :user profile rather than using lein plugin install. That way there is only ever one plugin list active at a time, meaning it can be de-duplicated, avoiding messy conflicts.

But you can also create profiles for other situations:

(defproject clj-http "0.3.3-SNAPSHOT"
  :description "A Clojure HTTP library"
  :url "https://github.com/dakrone/clj-http/"
  :min-lein-version "2.0.0"
  :dependencies [[org.clojure/clojure "1.3.0"] ; elided below...
                 [org.apache.httpcomponents/httpclient "4.1.2"]
                 [cheshire "2.2.0"]]
  :profiles {:dev {:dependencies [[ring/ring-jetty-adapter "1.0.2"]
                                  [ring/ring-devel "1.0.2"]]}
             :1.2 {:dependencies [[org.clojure/clojure "1.2.1"]]}
             :1.4 {:dependencies [[org.clojure/clojure "1.4.0-beta1"]]}}
  :aliases {"all" ["with-profile" "dev,1.2:dev:dev,1.4"]})

Here you can see the :dev profile with some handy dependencies used for testing, but there are also profiles for :1.2 and :1.4 that can be used like lein multi. The with-profile task is used to apply alternate profiles to a given task run:

$ lein with-profile dev,1.2 test
Performing task 'test' with profile(s): 'dev,1.2'

Testing clj-http.test.client

Testing clj-http.test.cookies

Testing clj-http.test.core

Ran 47 tests containing 175 assertions.
0 failures, 0 errors.

You can see that commas allow multiple profiles to be specified at once. You can also use colons to chain together profile sets sequentially:

$ lein with-profile dev:dev,1.2:dev,1.4 test
Performing task 'test' with profile(s): 'dev'
[...]
Performing task 'test' with profile(s): 'dev,1.2'
[...]
Performing task 'test' with profile(s): 'dev,1.4'
[...]

Of course, since with-profile is a higher-order task, it can accept any other task as an argument, not just test. So you could use it for deploying to different environments or any place where you'd want an alternate set of project configuration values.

Aliases

You'll also notice that the :aliases entry in the defproject above maps a string to a vector. This is a new feature about which I am unreasonably pleased. You've always been able to add aliases for Leiningen tasks; this is how lein halp has worked. But now you can actually alias a string to a partial application of a task:

:aliases {"all" ["with-profile" "dev,1.2:dev:dev,1.4"]}

This means that all test translates into calling with-profile dev,1.2:dev:dev,1.4 test. But partially-applied aliases have other uses as well:

:aliases {"reflect" ["assoc" ":warn-on-reflection" "true" "compile"]}

This allows you to invoke lein reflect to get a list of all your reflection warnings. Note that in this case assoc refers to the task that comes from the lein-assoc plugin, not the clojure.core/assoc function. Each string in the alias vector is interpreted the same way as if it were a direct command-line argument to the lein script, which is why strings must be used. In this case reading it into keywords and booleans happens inside the assoc task.

And that's one of the neat things about having tasks as functions.

Repl

The repl task has been rewritten from the ground-up by Colin Jones. The new version supports a JVM-native readline implementation as well as thorough completion and nREPL support.

Preview

By this point I'm sure you're thinking to yourself, "Gosh, that sounds super; I wish I could use it now!" In fact, Leiningen 2 is already pretty usable and stable if you don't mind running from git. You need a copy of Leiningen 1.x around to bootstrap it, but running lein install inside the leiningen-core directory should get you to the point where you can symlink bin/lein to somewhere on your path and have it work. I recommend linking it as lein2 for the time being since you'll probably still need an installation of 1.x easily accessible.

Of course, being a major version increment it's got some backwards-incompatibilities. Fresh from witnessing the very bumpy transition to Clojure 1.3, I'd rather avoid that for Leiningen 2, so taking a cue from golang's gofix tool, I've released the lein-precate plugin.

Precate, obviously, is the opposite of deprecate. The idea is that you could run it on your project and have it spit out a new project.clj which would be compatible with Leiningen 2. It's not perfect, but it should provide you with a starting point for your transition:

$ lein plugin install lein-precate 0.3.0
$ cat project.clj # the original 1.x-compatible version:
(defproject clojure-http-client "1.1.1-SNAPSHOT"
  :description "An HTTP client for Clojure."
  :source-path "src/clj"
  :extra-classpath-dirs ["dumb-stuff"]
  :dev-dependencies [[swank-clojure "1.3.4"]]
  :dependencies [[org.clojure/clojure "1.2.1"]
                 [org.clojure/clojure-contrib "1.2.0"]])

$ lein precate # let's see how that would look for Leiningen 2
(defproject clojure-http-client "1.1.1-SNAPSHOT"
  :description "An HTTP client for Clojure."
  :source-paths ["src/clj"]
  :dependencies {org.clojure/clojure "1.2.1", 
                 org.clojure/clojure-contrib "1.2.0"}
  :profiles {:dev
              {:resource-paths ["dumb-stuff"],
               :dependencies {swank-clojure "1.3.4"}}}
  :min-lein-version "2.0.0")

Unfortunately that output had to be manually edited a bit for cosmetic reasons; Clojure's pretty-printer doesn't really know what to do with defproject forms. But it should cover most of the changes necessary to take your project into the exciting new world of Leiningen 2. The biggest changes will come from the move from :dev-dependencies to :dependencies in the :dev profile. But this is not a foolproof translation since in Leiningen 2 :dependencies only run in the context of the project itself, while in Leiningen 1 :dev-dependencies ran in both Leiningen and the project. In retrospect this was a design mistake, but there are a number of plugins out there that take advantage of this fact and will need to be split into separate artifacts for the parts that run in Leiningen vs the parts that run in the project. I've taken some time to adapt some of the most commonly-used plugins for this change, but I'm sure I missed some of the more obscure ones.

The plan from here is to polish off a few more features and cut a preview release. The preview will still be missing a handful of the more obscure features from Leiningen 1 like shell wrappers and selective transitive class file cleaning, but for the vast majority of projects it should be usable for everyday work. See the "post-preview" section of the todo file for details on what's remaining. The hope is to have it ready at latest by the Clojure/West conference. Enjoy!

Update: Leiningen 2.0.0 has been released! See the upgrade guide.

in which an interview is posted

2012-01-27T03:58:25Z

The folks over at The Setup just posted an interview with me wherein I rant about hardware, interactivity, and Emacs.

Note: this was written up over a month ago; if I were interviewed today I couldn't help but mention the Nix package manager. I use it on my Debian Squeeze system to complement apt-get; I get all the system-level stuff that has to be stable from Debian and anything that needs to be fresh from Nix.

in which local hacking locations are surveyed

2011-12-31T02:25:58Z

I'm lucky to have the chance to do my job remotely from wherever I like. Half the time I work out of my code lab, which is a converted shed in my back yard. But I venture out fairly frequently to local coffee shops. Here are a few of my favourites. I should mention that I'm a big fan of single-origin pour-over brews, so the list is biased in favour of places which serve that well rather than the more traditional espresso drinks. All these have at least one location in North Seattle.

Neptune

I'm here a lot because it's the only one on this list I don't need to get on the freeway for. The decor is a bit sparse, but they're quite friendly here and serve a mean pour-over. They've been known to even serve syphon-brewed coffee, which is always a treat to watch when they fire up the bunsen burner. The proprietor also runs tehcoffee.com, a (Heroku-hosted) site for competition-level baristas can rank and review others. The Greenwood neighborhood is great too; lots of lunch options and bookstores to browse. Bonus fact: Allie, the inventor of the mythical Alot beast has a blend here named after her.

Milstead & Co.

This one has only opened relatively recently, but it's made a splash for a number of things, not the least of which is the spectacular waterfront view from under the Aurora bridge. The selection here is excellent; this is the only place on this list that serves beans from multiple roasters, and they offer plenty of variety in brewing methods. The interior is spacious with high ceilings; it's very inviting. Mr. Milstead himself is usually around, and his excitement about his craft is infectious and obvious once you get him talking. I'd be here all the time if it weren't the furthest (south) from where I live.

Zoka

This one is my go-to place. I often run into people I know here, (and sometimes people I don't), and we hold the Seattle Clojure group meetings here as well. The University District location in particular works well for meetings just because it's so spacious; I don't think I've ever seen a larger coffee shop. It's a popular place for students to study, so it's pretty quiet in the back. It can be crowded at times though, probably based on the school schedule. They've got a great selection sourced from all over the world that rotates every so often. It's always fun to read their blog posts about traveling to visit the growers. The "Zoka bars" they serve here are a ridiculously rich treat. The decor here is very warm and comfortable with wood paneling everywhere.

Trabant

I don't come here often because the parking situation is awful, but if you are in the area (or taking the bus), definitely check out Trabant. They've got good chai, but the thing that keeps bringing me back here is the Clover machine. This contraption is capable of extracting rich flavours out of a bean like nothing else. Unfortunately Starbucks purchased the company that sold them, so there aren't very many places with Clovers that offer good beans. (As the owner of Trabant said about the acquisition, "wearing Air Jordans doesn't make you play like Michael Jordan.") Anyway, the downtown Trabant is very spare, minimalist, and quiet, while the one in the University district (pictured) is bustling and quirky.

Honorable Mentions

Vivace: I'm of the opinion that Vivace has the best espresso in Seattle. It's too far for me to visit regularly, but members of the famed Seattle Ruby Brigade can often be found working here in the afternoon.
Seattle Coffee Works: I've only been here a couple times, but I was floored by their Yirgacheffe both times. They serve their pour-overs at a separate "slow bar" where the baristas are happy to geek out over their creations if you show interest. Again, this one's too far away (Pike St.) to make me a regular.
Green Bean: This one is actually a non-profit which supports a number of other non-profits on a rotating basis. The staff here are really friendly. I like to come here early and get breakfast with my family since they've got a kids' corner.
Chocolati: I don't even come here for their coffee, but their hot chocolate is superb. They've also got great truffles. The Greenwood location is a converted house that offers plenty of space to work, while the Greenlake location is a lot smaller but has nice views of the water.

in which version two seems a treacherous stage

2011-12-01T07:15:11Z

I recently got back from the Clojure Conj conference in Raleigh. The sessions were great, but the main highlight for me was meeting with the developers of Cake (an alternate Clojure build tool) and discussing how we could collaborate on the future of build tools in Clojure. As was announced elsewhere, we will be taking some features from Cake and merging them into Leiningen 2.0 as well as just having more hackers involved in development efforts.

The development of Leiningen 1.x pretty much just fell out of the usage patterns we saw during my time at Sonian as an early adopter of Clojure. We used Maven for eight months, tried to make it work, and then took our experience from the pain we saw there to Leiningen. Some features (especially checkout dependencies) arose directly from finding certain operations with multi-module Maven builds extremely cumbersome. But in general nearly everything about Leiningen so far has been obvious. I wouldn't say it practically wrote itself, but once the central model of a project map and resolving/applying tasks from defns was established, the only really tricky thing was being strict about establishing a narrow scope and knowing when to avoid adding features.

"Version 2" is the most dangerous phase in a software project's life.

— Chas Emerick

So now we're digging into the question of what bigger-picture changes could be made to improve Leiningen if we leave backwards-compatibility out of it. The biggest improvement we've seen implemented so far is switching over dependency resolution to the Aether library via Chas Emerick's Pomegranate library. Aether is a library that contains all the dependency management features from Maven extracted into an independent module—basically designed with exactly Leiningen's use case in mind.

But there's more coming. Cake has had the ability to run project code in the same process as the build tool, significantly speeding up many operations, which is in the process of being ported over to Leiningen. I've been working on explicitly delimiting the parts of Leiningen that comprise its public API as part of a separate "leiningen-core" library which other tools can depend upon. We're looking at adding something like "profiles" do bundle up configuration sets which can be activated in given contexts.

With all these ideas flying around I hope we can buckle down and get some solid design discussions resulting in well-factored features. If you've been looking to contribute, now is a great time. Join the #leiningen channel on Freenode and hop on the mailing list.

in which the lesser-known are brought to the forefront

2011-10-28T17:21:54Z

In my time hacking in Clojure I've found a bunch of under-appreciated Clojure libraries of which I'm rather fond. I thought it'd be helpful to share, so here they are:

lein-multi

As support for Clojure 1.3 becomes widespread, it becomes more important for projects to think about backwards compatibility. You can specify a range of versions for Clojure in project.clj with [org.clojure/clojure "[1.2.0,1.3.0]"], but when you're developing, it will just find the latest and pull that in, so it's easy for dependence on 1.3-specific features to sneak in.

Enter lein-multi, a plugin for running arbitrary tasks against multiple dependency sets. It's most commonly used with the test task, but it's a general higher-order task that can be applied to any other just as well. Seeing lein-multi in someone's project.clj is a good indicator that they take backwards-compatibility seriously.

Update: Leiningen 2 supports this out of the box using profiles, so the lein-multi plugin is deprecated.

[lein-multi "1.0.0"]

clj-stacktrace

The most common complaint I hear about developing in Clojure is the fact that its error messages often obscure the true cause of the problem. While practice helps here, it's still true that there's a lot of irrelevant detail here that can overwhelm the trained eye. Mark McGranaghan's clj-stacktrace library does a great job at summarizing stack traces by aligning each frame, making the namespace distinct from the function name, and even coloring frames differently based on whether they come from Clojure, Java, or user code. The next version should let you filter out frames that are deemed irrelevant on a per-project basis.

To use it in your project's repl as well as in clojure.test error reporting, place this code in ~/.lein/init.clj after running $ lein plugin install clj-stacktrace 0.2.4:

(require 'leiningen.hooks.clj-stacktrace-test)

(def settings {:repl-options [:init (require 'clj-stacktrace.repl)
                              :caught 'clj-stacktrace.repl/pst+]})

slingshot

Another common question you hear is "How do I generate custom exception classes?". It's awkward and somewhat un-idiomatic to do this, so people generally try to get by with the Exception classes that ship with the JDK. But why shouldn't exceptions get the same level of dynamicity and flexibility that Clojure affords other data types?

This is basically the question Slingshot addresses. It provides enhanced try+ and throw+ counterparts to the built-in error mechanisms that let you throw arbitrary data types like maps. Then rather than dispatching in your catch blocks based on class, you can use arbitrary predicates. You can even perform destructuring on maps that are thrown. It's a big step up in expressiveness:

(defn asplode! []
  (throw+ {:bad? true :tachyon-level 21}))

(defn ignorable? [e]
  (and (:silent e) (not (:fatal? e))))

(try+ (asplode!)
  (catch ignorable? _)
  (catch :bad? e
    (log/warn "Bummer dude!" e))
  (catch :fatal? {:keys [exit-code]}
    (System/exit exit-code)))

Update: The equivalent of the exception-throwing side of Slingshot has been included in Clojure 1.4 using the ex-info and ex-data functions, so unless you are targeting old versions of Clojure you should use those instead. Nothing has been added on the exception handling side though, so Slingshot's try+ macro is still very useful.

[slingshot "0.8.0"]

lein-difftest

If you've ever written a test where you expect two lengthy data structures to be equal, you'll remember how annoying it is to try to compare the failure message where "expected" and "actual" are each spat out on a single line and you're supposed to try to hunt down the difference. Using lein difftest makes it easy:

It also uses clj-stacktrace to report errors. This one is better off installed as a user-level plugin since you're likely to want to be able to use the difftest task across all your projects:

$ lein plugin install lein-difftest 1.3.7

Update: Use version 2.0.0 of lein-difftest for compatibility with Leiningen 2.x.

robert-bruce

From the do-one-thing-and-do-it-well department, we have Robert Bruce, which concerns itself only with determinedly retrying a given function. It provides all the options you could imagine for how to perform the retries, including pausing between them (with exponential decay on backoffs), retry limits, callbacks on failure, and so on.

[robert/bruce "0.7.1"]

Happy hacking!

Do you have a favourite that I've missed here? Leave a comment about it. Remember that the version numbers provided here are current as of the time of this writing but may be outdated when you read this.

in which version two turns the inside out

2011-09-28T04:12:54Z

I just got back last week from the Strange Loop conference in St. Louis. The conference showcased some really quality keynotes and session talks, but I had been invited to give a workshop teaching Emacs, which was a blast. The workshop was three hours long, but I still felt like I was zooming through. My outline is available, though it may not be all that useful unless you were there.

The talk focused on the task of crafting your own set of dotfiles. Naturally I did talk some about the Emacs Starter Kit, though my approach there has changed fairly radically. I've been developing version 2 of the Starter Kit since the beginning of the summer, but now I think it's time to make the release official and give it wider exposure.

The Emacs Starter Kit, version 2

Version 2 of the Starter Kit turns things inside out. The original version was very prescriptive; you used it by cloning a git repo to use as your entire ~/.emacs.d directory, and you fit your own customizations inside the structure it provided. This was mostly due to the fact that when it was released the packaging story for elisp was very immature. Use of package.el was not very widespread, so the Starter Kit had to include a copy as well as bundle a bunch of libraries that had not been packaged yet. As it turned out, I think the Starter Kit had a role in helping popularize package.el.

A lot has changed since 2008—primarily that package.el has been included in Emacs and Marmalade has picked up lots of steam, becoming the de-facto community package source with over 250 packages. It's now feasible for the Starter Kit to be distributed as just another package, leaving you free to structure your dotfiles however you like. All it takes is setting yourself up to get packages from Marmalade:

(require 'package)
(add-to-list 'package-archives
             '("marmalade" . "http://marmalade-repo.org/packages/"))
(package-initialize)

Place that in ~/.emacs.d/init.el and evaluate it with M-x eval-buffer. From there you can run M-x package-refresh-contents to pull in the latest package lists (analogous to apt-get update) followed by M-x package-install starter-kit. And then you're set.

However, it's unlikely that the starter-kit is the only package you're interested in. Rather than picking packages by hand, I'm a fan of keeping a list of all the packages you use in your dotfiles. That way when you move to a new machine, you won't have to remember what packages you've come to depend upon; checking out your dotfiles on a new machine will pull in everything you've specified. Here's my list along with some code to handle it:

(when (not package-archive-contents)
  (package-refresh-contents))

(defvar my-packages '(starter-kit starter-kit-lisp starter-kit-eshell
                                  starter-kit-bindings scpaste
                                  clojure-mode clojure-test-mode
                                  markdown-mode yaml-mode tuareg
                                  marmalade oddmuse scpaste))

(dolist (p my-packages)
  (when (not (package-installed-p p))
    (package-install p)))

What's Changed

Being a 2.0 release, you can't expect 100% backwards compatibility with the old Starter Kit. In particular, it is much more modular. The base of the Starter Kit simply gives you better default settings and a few new commands. There are separate modules supporting various languages like Ruby, Lisp (Clojure, Emacs Lisp, Scheme, and Common Lisp), and Javascript, though right now the Lisp one is the most polished. If anyone is interested in helping maintain alternate language modules, please contact me on Github. Key bindings have also been spun out into their own module since they don't follow Emacs binding conventions strictly.

There is also no more elpa-to-submit directory; if you rely on packages that aren't on Marmalade yet, it's up to you to either check them into your own dotfiles or better yet upload them yourself. There's also no more explicit recentf support since a new feature called ido-use-virtual-buffers allows recent files to show up in the regular C-x b buffer switcher, simplifying things. The addition of the ido-ubiquitous package makes it so regular completion gets enhanced with ido magic, so functionality like ido-imenu is no longer needed.

The other breakage is that the Starter Kit is now intended only for use with Emacs 24 onward. Yes, technically Emacs 24 has not yet been released, but it's in active pretest and is readily available for most platforms.[1]. I've been using it since 23 was released and have had no trouble with it.

[1] It's not hard to compile from source, but precompiled versions are readily available for Debian-based systems, Mac OS X, and Windows.

in which static types are friends, not foes

2011-08-15T01:37:00Z

I'm a big fan of composability in user interfaces. Unix has traditionally been strong in this area with its culture of pipes and standard in/out, making it easy to chain together small tools with orthogonal purposes. Unfortunately this usually does not extend to GUI tools which often tend towards monolithic globs of functionality. There are a few exceptions, my favourites including xbindkeys and mpd.

The most versatile of these I've found has been dmenu, a graphical option chooser in the style of Emacs' ido-mode: it presents a list of options, and as you type it narrows to just the options which match the input that's been entered so far. I've built a number of tools on top of this including a music frontend to mpd and a script that allows me to perform a number of Skype actions from the keyboard.

The problem is that dmenu is pretty minimalistic compared to ido. The main annoyance to me is that it doesn't support flex matching—in other words, only exact matches are shown. In Emacs, ido lets me match a few characters against the front of the string and a few against the tail. Any input is accepted as long as it uniquely identifies one of the choices. Since dmenu is written in C I didn't exactly relish the idea of picking up skills in that language to add this functionality, so I wrote a replacement in OCaml instead:

let rec read_lines lines =
  try read_lines (read_line () :: lines)
  with End_of_file -> lines

let lines = read_lines []

let lines_matching pattern matched line =
  try let _ = Str.search_forward pattern line 0 in 
      line :: matched
    with Not_found -> matched

let escape = function
  | ' ' -> ".*"
  | c -> Char.escaped c

let pattern input =
  Str.regexp (String.concat "" (List.map escape input))

let matched input lines =
  List.fold_left (lines_matching (pattern input)) [] lines

let rec draw_matches matches =
  Graphics.open_graph " 1440x15";
  Graphics.set_window_title "erythrina";
  Graphics.draw_string (String.concat " | " matches)

let finish input lines =
  Graphics.close_graph ();
  match matched input lines with
    | f :: _ -> print_string f
    | [] -> ()

let butlast input =
  match List.rev input with
    | [] -> []
    | _ :: rest -> List.rev rest

let rec main input =
  draw_matches (matched input lines);
  match Graphics.read_key ()  with
    | (* enter *) '\r' -> finish input lines
    | (* escape *) '\027' -> Graphics.close_graph ()
    | (* backspace *) '\b' -> main (butlast input)
    | (* any other *) c -> main (List.append input [c])

let _ = main []

In 39 lines of OCaml I've achieved near feature-parity to the 700 lines of C that make up dmenu. The only missing features are tab-completion and font/color customization, though I have added the flex-matching feature mentioned above that dmenu lacks, which makes tab completion less important.

This is my second foray back into the land of static typing since university. (Supposedly I learned C++ in school, but I've long since mercifully forgotten it all.) I picked up Mirah last year and spent a little more time hacking in it earlier this year for an Android app. While Mirah is a huge improvement over Java, its type inference unfortunately only extends to locals, (a common shortcoming of most JVM-hosted type systems from what I gather) meaning if you tend to write small methods you end up specifying all your types anyway. OCaml on the other hand infers all types using Hindley Milner inference, allowing the types to be effectively invisible.

I've only spent a few days writing OCaml, but I've got to say I'm impressed. The type system stayed out of the way, only making a fuss when I'd clearly made an error. Pattern matching is a dream: you'll notice that all the conditionals in the code above come from match rather than if. It's fast, it's pleasantly interactive, (especially via tuareg and Emacs) and the executables produced by the compiler are tiny and quick to start, which is valuable for anyone who spends a lot of time on the JVM and is looking for something to fill those pesky gaps for which the JVM is admittedly lousy.

My only real complaints surround the fact that the standard library is slim and quirky. It throws exceptions in places you wouldn't expect, like hitting the end of the file while reading or searching for a regex when the text contains no match. The regex support is a bit odd, but that's not too surprising considering how old the language is.

Of course the standard library is augmented by a number of third-party libraries. It seems like up until recently it's been assumed that you'll use either apt-get as the main way to pull these in or run make install from source. As I've blogged about recently, apt-get is a bit of a drag for libraries that are obscure or change frequently. It looks like Oasis is making it easier to build projects while ODB is the beginning of a rich library dependency system, though it's still got a long way to go. My needs have been simple enough that I've been able to stick with the standard library for my current project, but it's great to see progress in this direction.

Anyway, it's always a bit disorienting to toss yourself into a new environment like this. But OCaml has proven to be quite a treat. I recommend starting with this OCaml Tutorial which also links off to many other helpful resources. Have fun!

Update: As of version 4.5, dmenu has implemented fuzzy matching, making erythrina interesting mostly for educational purposes.