On Tue, Apr 5, 2011 at 09:30, Reinier Zwitserloot <[email protected]> wrote: > 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.
I find nothing to disagree with here, except to point out that seven package statements do not make for a "MASSIVE" increase in much of anything. The Clojure solution is simplified relative to my Java solution. There are a number of factors that contributed here: For one thing, the Clojure version was written second (some years after the Java version). Normally this is a clear win, since one can assume the problem is better understood when implemented the second time. (Not having touched the code for 5 years, I'm not sure how much this is a factor here.) But, it's certainly true that I have changed as a programmer in the 5 years since I originally wrote the Java version. There is also a cultural factor. There's something about the culture of Java development that seems to drive developers to one degree or another of architectural astronautics. The language establishes certain norms, (e.g. static typing), but the mechanisms used to achieve this (e.g. declaring classes) are wordy. The standard libraries also don't set a good example WRT simplicity. All of this leaks into the software we write. Sure, having now written the Clojure solution, I could go back to the Java solution and simplify it by, for example, eliminiating the Glyph classes and using plain ints. But, I'd be losing some static type safety. I'm sure there are other simplification I might make inspired by the Clojure solution, but as I did so, the Java solution would become ever less idiomatic. // Ben -- 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.
