On 18 June 2010 05:57, Mark Engelberg <mark.engelb...@gmail.com> wrote: > I assume that most Clojure users really like its dynamic nature. If > this is true, then for most of us, the common case is to NOT annotate > our code with types. Certainly I like the idea of making it as easy > as possible to write fast code in Clojure. I want my dynamically > typed code to be as fast as it can be, and it's nice to know that > there is a way to write statically typed code that is even faster. > But I really don't want to incur a penalty (i.e., possibility of > Arithmetic Exception) when I'm not using type annotations. > > I agree that the burden on those who want to write type annotated code > is too high. I agree that this should be made easier. But > ultimately, I still want the burden to be on them (or me, the 1% time > I need it), not those of us who prefer unannotated code. I that some > of the changes you have proposed for moving the annotations into the > header, along with literal notation for long (i.e., 0L rather than > (long 0)) would be preferable to the bigint dichotomy.
QFT -- I'm in absolute agreement. It seems to me that in its current shape, the new design -- actually the "no automatic promotion/demotion" part -- would amount to sacrificing correctness for performance *by default*; that doesn't strike me as a good way to go. Not a single language I like using does that... this of course includes my favourite language, Clojure, as it currently stands on the master branch. :-) Part of the reason why I think this is a bad idea is that while it is all very well to say that people should know what they're doing, libraries should be well-designed and have excellent test coverage etc., this is not what happens in practice. (It's also perfectly possible to write correct concurrent programmes with locks...). And not necessarily through lack of dilligence; I know I have learned many a gotcha by getting bitten by it (and rather expect to accumulate plenty more "bites" in the years to come). I suppose that's fine as long as one is learning something useful in the process, but I should think that top numeric performance is something required only by a certain part of the community -- a sizeable one, no doubt, but hardly a majority share -- in fact comprising the people most likely to know what they're doing when dealing with numbers (why would someone *not* doing involved numeric computations know what s/he's doing with numbers on a comparable level to someone who is?). Making things significantly easier for them would be welcome, of course, but perhaps not at the cost of making *everyone* deal with entirely new kinds of complexity to support that. I wouldn't know if the "good" solution Antony Blakey mentions is feasible currently, but if it isn't, I'd prefer the language to err on the side of caution, while perhaps offering a better system for hand-annotating things for top performance (some people have been using pretty ingenious macros to ease things a little -- perhaps these could be improved upon to produce an acceptable close-to-universal solution)? Right, so these are my initial impressions. I'll continue thinking about this, the new developments do seem attractive in many ways (^:static is very cool indeed!) and I'm curious to see if I might be able to bring myself to see more positive sides to the long/bigint split (as well as come to an opinion on the equals issue). All the best, Michał -- 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
