I'm just one voice on the side that's been advocating for auto-promotion by default. For what it's worth, I completely see where the other side is coming from, and if Rich sees primitive math by default as important to Clojure's future, then so be it. It sounds like he's given it a lot of though and has a pretty strongly held opinion at this point. That is, unless he's just playing devil's advocate.
I would, however, like to throw some support behind Mike Meyer's suggestion that the arbitrary precision numeric tower use names like add, sub, mul, div, inc, dec, while the "default" ops keep the symbolic names. I think it was Luke who suggested, and I agree, that it would be unfortunate to have to teach new Clojurians about machine math just to allow them to understand Clojure math. For new users, and also for people like me, it would be nice to having names for the arbitrary precision numeric tower that don't sound subordinated or second-class. I also think Mark's idea of removing support for bigints and bigdecimals from the default ops is worth discussing. It seems cleaner to me than overloading the default ops and thereby making people complacent. Garth On Tue, Jun 22, 2010 at 1:13 PM, Mike Anderson <mike_r_ander...@yahoo.co.uk>wrote: > On Jun 22, 1:27 pm, David Nolen <dnolen.li...@gmail.com> wrote: > > On Tue, Jun 22, 2010 at 6:04 AM, Heinz N. Gies <he...@licenser.net> > wrote: > > > > > > > > > > Yes. With Rich's primitive work we can get to *1 billion arithmetic > > > operations* in < 2/3 of a second on commodity hardware. > > > > > Which is absolutely great since I always wanted to do that :P > <sarcasm/>, > > > meaning the example is kind of far fetched even compared to fact (which > is > > > working code with useful results). > > > > Perhaps you aren't interested in using Clojure for graphics or audio > work. > > > > David > > Most of my code does fairly intensive graphics work. I'd love to be > able to write > it all in Clojure but currently (sadly) it is often easier for me to > write the processing > code in Java and use on the Java interop to call it. > > Also if anyone is interested in real-time performance (games, > animation etc.) then > lots of small boxing allocations can be unhelpful in terms of > increasing the number > and severity of GC pauses - to some extent that's even worse than the > overall > performance hit. > > Aside from my personal utility and preferences (which are compelling > for me!) > I'm in the "primitive by default" camp for a few reasons: > > 1. The "pay for what you use" argument is very convincing > 2. It's more conceptually close to what Java/C# developers are used to > so it helps > with the learning curve > 3. Primitive by default is going to work much better for non- > mathematical uses > of numbers (array indexes, simple loops, counts of collection sizes > etc. ) which > I believe is the common case rather than heavy-duty mathematics with > huge integer ranges > 4. It minimises the risk of a "Clojure is slow" reputation developing. > Which you are > likely to get if people start comparing micro-benchmarks of non-hinted > code against > languages with static / primitive support. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com<clojure%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
