Clojure++ (notes from Rich Hickey talk)
combinate.us
Clojure++ (notes from Rich Hickey talk)
1–10 of 45 posts
Re: Clojure++ (notes from Rich Hickey talk)
#2"... most numeric functions in Clojure, will no longer auto-promote values to Big numbers..."
Oh no! Clojure is choosing the route of premature opt. What a terrible shame.
Re: Clojure++ (notes from Rich Hickey talk)
#3"... most numeric functions in Clojure, will no longer auto-promote values to Big numbers..." Oh no! Clojure is choosing the route of premature opt. What a terrible shame.
This is only true if you use the annotations, at least that is my understanding.
Re: Clojure++ (notes from Rich Hickey talk)
#4shouldn't it be called (++ clojure) or something like it?
Re: Clojure++ (notes from Rich Hickey talk)
#5"... most numeric functions in Clojure, will no longer auto-promote values to Big numbers..." Oh no! Clojure is choosing the route of premature opt. What a terrible shame.
I was at the talk in question. Some more context:
Bignums "contaminate" surrounding operations. Adding a long and a bignum yields a bignum. Seeding an equation with a single bignum (42N is a bignum representation of 42) will prevent overflow.
No one has come forward with a single real-world scenario where they're using bignums in Clojure. Choosing a default that is only theoretically useful rather than a 10x performance improvement seems a bit silly.
In any situation where the compiler cannot be sure you're using primitives everywhere, it will emit non-overflowing bytecode.
By my measure, there's nothing premature about this optimization. In Rich Hickey's words, Clojure is a replacement for Java, not Ruby. Giving up Java-like performance makes the language quantitatively less useful.
Re: Clojure++ (notes from Rich Hickey talk)
#6shouldn't it be called (++ clojure) or something like it?
Or (inc clojure) perhaps? Isn't (++) an abomination in functional programming with immutable state?
Re: Clojure++ (notes from Rich Hickey talk)
#7"... most numeric functions in Clojure, will no longer auto-promote values to Big numbers..." Oh no! Clojure is choosing the route of premature opt. What a terrible shame.
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 libraries or deploying apps into production.
Re: Clojure++ (notes from Rich Hickey talk)
#8Hmmm, Kawa's been doing this for better part of a decade. I tried this in kawa:
(def (fib n :: ) ::
(if (Re: Clojure++ (notes from Rich Hickey talk)
#9Hmmm, 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.
Rich is not trying to improve over Kawa. He's trying to improve over previous versions of Clojure.
Re: Clojure++ (notes from Rich Hickey talk)
#10shouldn't it be called (++ clojure) or something like it?
Or (inc clojure) perhaps? Isn't (++) an abomination in functional programming with immutable state?
++ isn't defined in Clojure, and in Haskell ++ is used to concatenate lists. Using (inc) isn't considered an abomination, though.