When I first started learning Clojure I was surprised at how concise it actually is. I was so used to scanning imperative code in huge jumps, that the conciseness caught me completely off guard and I would scan functions without even taking it in. Every.Single.Word matters in Clojure, there is literally zero boilerplate. So I agree that counting nodes is actually not a bad way to measure how much the code base grows over time.
> I also count lines when choosing libraries. When you depend on a library, the library code becomes your code in a way. [...] If two libraries do roughly the same thing, but one has far fewer lines, I will usually prefer the smaller library.<p>This is a little odd imo. Far more important when choosing a library are other aspects like its maturity, activity, interface width...<p>In fact, the goal in choosing a library should be to <i>minimize</i> the probability that the "code becomes yours." You should be looking for a strong and <i>stable</i> abstraction, first and foremost.
TL;DR; He wrote a tool that accurately counts the number of lines in a Clojure project (e.g. ignores comments, etc) and <i>also</i> counts the number of nodes in said project's AST.<p>I think an interesting metric would be number of AST nodes per line, maybe even providing the top N most complex lines, where complexity is number of nodes per line.<p>I find that some languages (Scala and Perl come to mind) tend to encourage extremely dense one-liners that have <i>way</i> too much going on with many tiny little temporary variables and symbols all crammed into a short amount of space.<p>A tool like this, if added to a linter could help discourage that sort of programming.
>Obviously<p>```
(f a
b
c)
```<p>> is the same "amount" of code as<p>> `(f a b c)`<p>Yes, obviously! But they do not take the same number of lines - one is three lines and the other is one line.<p>It's sort of funny to me- number of lines doesn't paint the picture we want it to... so let's change the metric! Our code is special, anyway.