LOC (Lines of Code) is not a good characterization of the quality of code; clarity and understandability is. The Clojure implementation is pretty nice on those counts.
The LOC measure may be important when, for example, the goal is to show the number of operations to be as small as possible.
LOC (Lines of Code) is not a good characterization of the quality of code
Actually it is. Or at least it's the best we have. When it comes to anything you can measure, the evidence points to program length as the best predictor of quality of code. And LOC is, for better or worse, the standard metric for code size.
Speaking of which, someone later told me that Chapter 27 of McConnell's Code Complete cites studies according to which bug count grows as a mild exponential function of code size. I don't have that book handy. If anyone does, can they look at Chapter 27 and tell us what it says?
Thanks, drallison. Generally speaking I agree, LOC alone is not a great metric of code quality, though it does roughly map to fewer places for bugs to be introduced when coding in the large, which is rarely a bad thing (though irrelevant for something like this).
In this case, I decided to implement it in a lisp after noticing that Pike's algorithm worked by consuming a character at a time off of both the pattern and the input text, lending itself naturally to a functional recursive implementation. Pike's version in C does this by advancing pointers, but it spoke equally well to an idiomatic car/cdr approach in a lisp (the recur/first/rest pattern you see in matchhere).
The LOC measure may be important when, for example, the goal is to show the number of operations to be as small as possible.