I'm going to re-organise this a bit… > On Jan 14, 2:40 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote: >> Debatable it is, endlessly. ;) So Clojure committers made a choice. >> Hopefully, they have made a choice that has:
I agree that they've made a choice, and I really don't want to be too critical here. However, since Clojure 1.3 is still in an alpha stage, maybe this discussion can still contribute something. Maybe what I'm saying is that I want to stay constructive and that there's maybe still time to be constructive. >> >> * a small positive effect (better performance with less effort) on a >> majority of users >> >> * a small negative effect (worse performance, extra effort) on a minority These goals are good, but I don't know that the approach taken achieves them. In my experience, errors are the problem and we should be avoiding them, almost at all costs. Numbers are confusing to people. Numbers approximated on a computer are far more confusing. How many times do you see threads discussing how a compiler is buggy because it can't divide two numbers and get the right answer? I've been doing this stuff for years and I can come up with an awful lot of amusing and/or horribly nasty examples. But I don't think this needs to be re-established. Given my experience I *strongly* lean towards not making a 'mistake' due to compiler optimisations. In other words, I'd be very annoyed, and I'd expect others to be annoyed too, if a numerical error was introduced to one of my programs because of an unexpected, silent, compiler optimisation. Secondly, Clojure has already established that we will use type annotations to signal to the compiler what's what. When we annotate, we are relaxing our requirements on the compiler to not make a mistake by assuming that responsibility ourselves. I would suggest the following: 1) if there's type annotation on both values of, say, an addition, then the optimised version can be used. If there isn't, or the compiler isn't sure, then use safe operations. 2) if the compiler isn't cooperating (because it isn't sure what's going on) we should be helping it by again assuming the responsibility of being right and marking the operator, say with a tick. And yes, this likely has problems too. I'm not saying that this is an issue with easy solutions. We're heading for a hodgepodge of annotation purposes, some for optimisation, some for correctness (and one of these days I'll mention what I think of the @/deref thing :-) And now we're pretty much guaranteed ugly code no matter what. Though I'd prefer no ugliness, I'd trade ugly code for speed, but I'd rather not for correctness. And there's a practical problem with mixed annotation purposes. If you want to track down a bug you can't just remove all annotations temporarily. You'd have to remove some and add others. Not looking forward to that. Maybe a macro: make-this-safe could be written. Hmm. Maybe a 'defn-safe' would be something to think about??? This is also the kind of thing that you just can't fix later. Imagine how we'll feel in ten or twenty years about this decision. >> >> -S > On 2011-01-14, at 8:40 PM, Armando Blancas wrote: > They used to give you compile switches for that kind of stuff, not > hope and wholesome wishes. Seems like every performance improvements > makes the language more complex, uglier or both. > Compiler switches were/are problematic too, but at least they are explicit and have to be *added*. Cheers, Bob ---- Bob Hutchison Recursive Design Inc. http://www.recursive.ca/ weblog: http://xampl.com/so -- 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
