These comparisons never really work. For example, the clojure code is all one gigantic file whereas the java variant is smeared out across 7 files. You did remove comments so this won't have quite as much impact on your numbers as it usually does (i.e. just raw LOC counting gives you a lot of hits on the repeated copyright headers).
Even assuming that simplicity is effectively defined by code length, you still have to accept that measuring chars (or words or lines) is a highly leaky abstraction to attempt to measure the true point which is the number of (AST) nodes, weighted by their relative complexity, possibly multiplied by the overall complexity of the model itself. This is more of an art than a science but we can at least try to zoom in on that number-of-nodes business. But, before I do, I have to point out you've cheated in a few places. As is virtually always the case, in an attempt to overestimate how much lines/words/bytes you can save with clojure, you've made your java code needlessly complicated, or, in this case, your clojure code oversimplified. Your java files ALL carry a package statement of "nom.bpsmithmannschott.poolrad". The clojure version first of all gets away with only 1 package statement (and I doubt anyone would try to claim that the duplication of the package statement across 7 files makes the java code more complicated) - but worse, in the clojure version, the package name is just "poolrad"! That would be cheating. I wonder how much of the gain you've found is left if you fix these things, i.e. count only 1 package statement and treat all namespaces equal. But let's get back to that nodal complexity issue. I doubt anyone would seriously claim that java's somewhat wordy import statements are actually a problem. No one ever types them (you either use an IDE and you never ever even look at it, or you use vim/emacs and you have some scripts to take care of it. If you don't, you're using java in a way that just isn't anything like normal java programmers do, so any hardship to you is unfortunate but just not relevant to the rest of the community). yet, your 7x repetition means you get a MASSIVE line number and byte/char count hit because of repeated and lengthy imports. I'd say its far more fair to disregard the entirety of the import list on both sides - at least, if the goal is to measure complexity and not, say, disk space. At the code level there are also plenty examples. Something as simple as a method declaration usually starts with 'public' but the actual complexity impact of this 1 word + 6 characters is far less than, say, an extra for loop or a synchronized keyword someplace. yet, both count roughly equal, which is strongly suggests a raw word/char/line count is not going to be nearly as enlightening as one might think. You yourself also mentioned clojure using int constants vs. java's enums. I'm sure most would agree that enums are on the whole a lot less complicated in the end than integer constants, and yet enums are _far_ more wordy. Java might well lose when it goes toe to toe witih clojure on the issue of general readability of code and ability to grok it as-a-whole. Possibly because java lacks closures which in certain environments leads to needlessly convoluted code. Sometimes code is simplified with temporal coupling, and clojure is going to work against you. Other times temporal coupling is just a needless complication, and java's strong preference for it (see e.g. Lists being mutable-by-default) means java loses the complexity fight. Maybe the answer is somewhere in between. Clojure is probably closer to the right answer than java is. I'm fairly sure a word/char/line count isn't going to be much help to determine this, though. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
