21–30 of 45 posts
Earlier quoted context omitted.
Premature? No people have been complaining (or just getting very confused) about Clojure's numeric performance without oodles of invasive type-hinting for two years now. More importantly with these changes it's now possible to reimplement Clojure's core datastructures in Clojure without sacrificing performance. The majority of people who care about BigInts are solving Project Euler problems, not writing Clojure libra…
2^63 numbers ought to be enough for anyone, huh?
I'm thirsty for counterexamples.
Hmmm, Kawa's been doing this for better part of a decade. I tried this in kawa: (def (fib n :: ) :: (if ( Almost identical speed results to Rich's "improved" version.
The did it for a dacade and rich does it for a couple months and you bash him? We arn't the kawa guys faster after a decade.
Clojure is faster in other stoff like interop witch is really importend on the JVM. Can Kawa write down-to-java speed types?
But: (defn ^:static fib ^long [^long n]) is really not sexy.
The ^long thing is pretty cool bettr then : or something. Its nice that it is just metadata.
shouldn't it be called (++ clojure) or something like it?
The changes are pretty substantial when you need them. I wrote a clojure implementation of Base64 that's faster than apache's commons-codec. In 1.2 it was about 5x slower.
Earlier quoted context omitted.
That Clojure's target is to replace slow old Ruby (actually that never happens, rather a successful language gains dominance in some niche and spreads from there) is only more evidence that it isn't worth breaking the abstraction called "numbers" to get merely an order of magnitude better performance. Seriously, I almost can't believe this is still an open issue in 2010. And Rich Hickey, who has designed such a great…
Clojure's target is to replace slow old Ruby That is very clearly the opposite of what I wrote.