Counting Clojure Code
aaroniba.net
Counting Clojure Code
1–10 of 13 posts
Re: Counting Clojure Code
#2When 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.
Re: Counting Clojure Code
#3> 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.
This is a little odd imo. Far more important when choosing a library are other aspects like its maturity, activity, interface width...
In fact, the goal in choosing a library should be to minimize the probability that the "code becomes yours." You should be looking for a strong and stable abstraction, first and foremost.
Re: Counting Clojure Code
#4TL;DR; He wrote a tool that accurately counts the number of lines in a Clojure project (e.g. ignores comments, etc) and also counts the number of nodes in said project's AST.
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.
I find that some languages (Scala and Perl come to mind) tend to encourage extremely dense one-liners that have way too much going on with many tiny little temporary variables and symbols all crammed into a short amount of space.
A tool like this, if added to a linter could help discourage that sort of programming.
Re: Counting Clojure Code
#5> 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. This is a little odd imo. Far more important when choosing a library are other aspects like its maturity, activity, interface width... In fact, the goal in choosing a library sh…
I think this heuristic is using lines-of-code as a proxy for simplicity, in the simple-vs-easy sense. All other things being equal, and presuming the difference is architectural rather than an artifact of a too-clever coding style, I would tend towards the shorter library too.
Re: Counting Clojure Code
#6> 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. This is a little odd imo. Far more important when choosing a library are other aspects like its maturity, activity, interface width... In fact, the goal in choosing a library sh…
I think this heuristic is using lines-of-code as a proxy for simplicity, in the simple-vs-easy sense. All other things being equal, and presuming the difference is architectural rather than an artifact of a too-clever coding style, I would tend towards the shorter library too.
Fair enough. In my experience it is rare to need library X and to have such an array of choices that LOC suddenly becomes the differentiator.
Re: Counting Clojure Code
#7> 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. This is a little odd imo. Far more important when choosing a library are other aspects like its maturity, activity, interface width... In fact, the goal in choosing a library sh…
I think this heuristic is using lines-of-code as a proxy for simplicity, in the simple-vs-easy sense. All other things being equal, and presuming the difference is architectural rather than an artifact of a too-clever coding style, I would tend towards the shorter library too.
Yes. You put it better than I did.
Re: Counting Clojure Code
#8Earlier quoted context omitted.
I think this heuristic is using lines-of-code as a proxy for simplicity, in the simple-vs-easy sense. All other things being equal, and presuming the difference is architectural rather than an artifact of a too-clever coding style, I would tend towards the shorter library too.
Fair enough. In my experience it is rare to need library X and to have such an array of choices that LOC suddenly becomes the differentiator.
I've never turned to LOC directly myself, but I have occasionally had to choose between 2 or 3 lone-wolf Clojure libraries to do a thing, and picked the one that seemed to have the sharpest focus or the most coherent implementation, which is usually the shorter one.
Re: Counting Clojure Code
#9> 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. This is a little odd imo. Far more important when choosing a library are other aspects like its maturity, activity, interface width... In fact, the goal in choosing a library sh…
I think this heuristic is using lines-of-code as a proxy for simplicity, in the simple-vs-easy sense. All other things being equal, and presuming the difference is architectural rather than an artifact of a too-clever coding style, I would tend towards the shorter library too.
> All other things being equal...
...but they're not. Perhaps one time in 50 you'll find a topic so well worn that you have choices between multiple mature, stable libraries with good APIs that lets you dig into the source code to see how nice it is (by whatever metric) to decide if you want to use it.
Perhaps what, json parsers?
I can barely think of any other examples.
It's a completely pointless metric.
The beauty of the API is far more important than looking into the implementation to see how it was written.
Heck, the library could be one giant regex on one line, but if the api is:
void *libfoo_random_meaningless_name(void *n, ...);
I very much doubt the elegance of the implementation is a metric that should be used to pick a library; there are far more important metrics to look at.
Re: Counting Clojure Code
#10TL;DR; He wrote a tool that accurately counts the number of lines in a Clojure project (e.g. ignores comments, etc) and also counts the number of nodes in said project's AST. 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. I find that some languages (Scala and Perl come to mind) tend to encourage extr…
It would be humorous, but instructive, to have something like this for Java that parses it and dumps out metrics about the tree size for a project - AST node count and static depth, where possible to tell.