Ok, I'll take that at face value then, but from the writing I sure got a different impression. This may be my language skills though, tone of voice is a subtle thing.
Quotes that are confusing to me:
> which (until the next release) is a bit slow on the JVM.
Is that meant as an apology for bad performance on one benchmark ? If so why apologize, in a benchmark all that matters is the facts, it's slow, or it's not.
You leave out the timings on this benchmark, concentrate just on the line count, which suggests in combination with the above that clojure performed less well than python but you left out that data. Or maybe it wasn't, but it would have been consistent to show run-times for all examples, code size for all examples (and coded up in roughly the same way), preferably gzipp'd to get rid of formatting bias.
> Might be a little confusing, but it's a great performance booster. << means bit-shift-left and
Who is your audience here ? Any programmer worth their salt recognizes a shift operation when they see one.
In your clojure examples you consistently count only the lines with code, in the python examples you count the blank lines as well.
Besides, who cares about line count when one language puts a whole pile of expressions on one line and the other does not, clearly, line count is not going to be a good metric to compare the one to the other.
You're also counting lines which define constants used only once and lines that print headers, the clojure program doesn't have those luxuries.
So, let's rewrite the python code like you wrote the clojure code:
from math import sqrt
def is_prime ( p ):
if p == 2: return True
if p <= 1 or p % 2 == 0: return False
for i in range(3, int(sqrt(p))+1, 2 ):
if p % i == 0: return False
return True
def is_mersenne_prime ( p ):
if p == 2: return True
m_p = ( 1 << p ) - 1
s = 4
for i in range(3, p+1):
s = (s ** 2 - 2) % m_p
return s == 0
for p in range(2, 33219):
if is_prime(p) and is_mersenne_prime(p): print("M%d"%p);
If linecount was that important than I could shorten it by quite a bit further, but I don't think it is a very useful metric, especially not if you count whitespace lines in one and not in the other.
Btw, this one is now 16 lines. Not as small as the clojure example, but less than half of what it was before, I'm sure a real python guru could shorten that by another couple of lines, essentially there is no real significant difference between python and clojure here.
The solution where you claim an impressive speed boost is mostly due to the simply running a bunch of tasks in parallel, which when opening stuff through the network is of course a big boon.
If the files would have been resident the test would have been more meaningful, otherwise you would have to compare apples with apples by running multiple crawlers feeding a single reducer.
And that would have been a sample worth making, but you couldn't be bothered. Then the clojure program would probably have been much shorter than the python one.
By the way, running that counting example on my computer here I get a time of 5:47, which is about twice as fast as your clojure run, wonder why that would be. It is also 24!! times as fast as the time that you report for python.
I'm not quite accusing you of cooking the books but it would be nice to have you find out what went so terribly wrong when you ran that test.
And so on. Really, I'm not impressed.
>