11–20 of 45 posts
shouldn't it be called (++ clojure) or something like it?
Or (inc clojure) perhaps? Isn't (++) an abomination in functional programming with immutable state?
See also, ADD 1 TO COBOL GIVING COBOL.
"... 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 performa…
EDIT: If peregrine's comment is right, then we're arguing about something that isn't happening. I hope so.
"... 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 libra…
"... 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.
Earlier quoted context omitted.
Or (inc clojure) perhaps? Isn't (++) an abomination in functional programming with immutable state?
(swap! clojure inc) is acceptable and a more literal translation, although refactoring your code to use (inc clojure) is usually more idiomatic. See also, ADD 1 TO COBOL GIVING COBOL.
Earlier quoted context omitted.
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 performa…
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…
That is very clearly the opposite of what I wrote.
But: (defn ^:static fib ^long [^long n]) is really not sexy.