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 For more options, visit this group at http://groups.google.com/group/clojure?hl=en
