Like Luke, I have been reading this thread with interest. For what it's worth, I'm in basic agreement with him.
I might take it a step further. I don't think anyone should have to think about boxing and primitives when writing standard idiomatic code -- code that uses +, *, loop, and recur. The joy of Clojure is, in my opinion, that it makes functional programming easy. How numbers are stored is an implementation detail that I would really prefer not to have to consider when doing something "easy." For the vast majority of applications, computers are fast enough these days to handle a little boxing and unboxing without anyone ever noticing. Many people younger than 25, especially casual programmers, have never programmed in a statically typed language. Many of my friends were introduced to programming in Python or Ruby or Mathematica or what have you, and have never used Java or C, and will never have any good reason to. Clojure is a good enough language in so many respects, in my opinion, that it will increasingly be used by casual programmers (perhaps mathematicians, economists, scientists, financial analysts) who need a powerful, simple, concurrency-oriented language to program their multicore machines. I think it would be a shame if the using the standard operations correctly required an understanding of concepts that are otherwise foreign to a dynamically typed language. Yes, people might get it right by accident most of the time because longs rarely overflow in normal use -- but getting it right by accident is not getting it right. Getting it right involves proper understanding. I am completely in favor of a parallel universe that makes it easy to optimize without filling one's code with type hints. If that parallel universe involves functions called +', *', recur', loop', that's great. In Mathematica, there's a contagious operator called N that you can wrap numbers in to make them machine numbers rather than arbitrary precision numbers (sort of an inverse of the num function in the latest proposal). I don't think the Mathematica system would work well here, but it's based on a principle I like: make all numbers auto-promoting (integers) and arbitrary-precision (floats) by default until the user specifically requests otherwise, and make it easy to request otherwise. I think transients fit the more general version of this principle perfectly, and it would seem strange to me to go in a different direction for numbers. These views are of course colored by my own needs (mathematical programming and statistics, where one sometimes deals with very large or small numbers if one is too lazy to work in logs). I know others have other needs. I'm sure a good compromise will be reached. It wouldn't be the end of the world if I had to use primed operators in my mathy code, but I would probably wince a little each time. Garth P.S. I don't consider loop-recur an advanced or performance-coding topic. It's the only way to get constant-stack recursion in Clojure. Many would consider recursion the most foundational of programming topics. On Sun, Jun 20, 2010 at 12:57 PM, Luke VanderHart <luke.vanderh...@gmail.com > wrote: > I've been reading this thread, and there's good arguments being made > both ways - I've just been reading with interest. But after seeing the > factorial function that won't compile without hints/casts, I feel I > have to speak up. > > I wrote a book on Clojure. It's a short book. That's because Clojure > is simple. It's dynamically typed, and everything "just works." In the > current version of Clojure, you can use numbers all day long without > worrying about types. Type hinting and casting is an advanced topic - > I think it should stay that way. > > It seems evident that some sort of compromise will be made on this > question. That's fine. I genuinely could go either way. But whatever > combination of features makes it into the final decision, they should > absolutely, vehemently not *require* knowing how to type hint or cast > just to get something basic to compile (as in the factorial example). > That is antithetical to the whole concept of dynamic typing. Having > exceptions thrown on overflow is ok with me - that's something > programmers are used to putting up with, I think, as long as the rules > are clear. I don't care what the rules are, as long as they're simple > to understand and based on a few axioms. If integers are bounded, > that's fine, if they automatically promote, that's fine, as long as > the rules are clear. If there's a separate set of math functions which > do or don't promote, that's fine. But don't, please don't, do > anything that would mean I'd have to explain the intricacies of > primitives, boxing, hinting and casting in an "Intro to Clojure" > course. As much as humanely possible, that should be reserved for the > "Performance coding in Clojure" sequel. > > Thanks, > -Luke > > On Jun 20, 6:39 am, Nicolas Oury <nicolas.o...@gmail.com> wrote: > > It seems to me that there is mainly 2 categories in this thread: > > > > - people that are worried about the difficulty to understand and to code > > with the throw-on-overflow semantic. They worry about untested cases > > showing in production code and the steeper learning curve of the > language. > > (I am not of this side, so please forgive me if I don't understand the > > argument well enough) > > > > - people that are annoyed to lose some speed everywhere in programs, in a > > way that can't be easily profiled or solved without annotating every > lines. > > People that also believe it is rare and predictable to overflow a long. > > > > I think both arguments are valid, and that most people won't change their > > mind on this subject. > > In consequence, I would like to advocate a proposal along the lines of: > > - A set of operations per return size, labelled by their size. +-long, > > +-boxed, +-float,+-double ... (I am not good with name, so I am sure > other > > people can come with better names) . They are overloaded on their > arguments, > > but indicate return size (I think that's what the last branch does, but > then > > again I might be totally wrong). > > - A set of operation without annotations : +, - ,... > > > > By default, these operators map to +-boxed, --boxed,... > > This solves the worries about the steep learning curve, because for > > beginners the story stops here. > > > > There is a flag allowing to change the default value, (or a namespace > > trickery, but it make it harder to apply to library code). > > > > That should come with some coding convention: > > - use +-boxed when you write a function that creates int exponentially > > bigger that its argument. (fact is in this category) > > - use +-long when you write code abound integers bound to a resource > > (indices, counters and the like...) > > - use the untagged operators in the other situations, +-boxed when in > doubt. > > > > I would also advocate that there should be a +-small family that is > either > > +-long or +-int depending on the platform. (+-long on modern computers, > but > > open the way to +-int on phones, or +-double on Javascript platform where > > there is no integer, if I am no wrong.) > > > > For those worrying about a semantic-changing flag, I would like to note > that > > it is not semantic-changing, it is only resource-size changing. > > You answer the question : what is the size of an integer? It is not > > different than choosing your heap size. > > > > If you don't have enough resource there is an exception (not a silent > > failure, so this is safe) and you can add more resources. > > > > I like this because: > > - it gives a clear story for beginners > > - it gives an easy way for people having very important production code > > (like a server), that does not need very high performance > > - it gives an easy solution for people having some code that need higher > > performance > > - it paves the way for other platforms > > - it is a pay-as-you-go approach, you don't have to understand any of > that > > before you need it. > > > > What do you think? > > -- > 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
