On Sun, Jul 31, 2011 at 10:27 AM, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > In principle the line is clear. Everything is fair game. Novel feedback is > always welcome. Question small decisions, question big ones. Press hard for > quality. > The opposite of providing novel feedback is recovering old ground. This > takes two (often overlapping) forms: > (1) Pushing an agenda when you aren't up to speed enough to be in the > conversation. > (2) Pushing an agenda when project leadership has said, "I understand your > feedback and disagree. This is not the direction we plan to pursue."
I'd say there's also (3) Covering old ground you didn't know had been discussed before. Though you might lump that into 1; but there's a difference between "not up to speed and should know it" and "not up to speed with no way of knowing it". (3) is most likely coming from a newbie. Another source of (3) would be if the previous discussions all took place elsewhere, such as IRC or the dev list, that the user hasn't been monitoring. >> You seem to feel that major, already-made >> design decisions that would require a fork and massive effort to do >> differently lie on the "shalt not question" side. What about more >> minor choices -- for example, which of the three kinds of primitive >> math overflow behaviors, throwing, auto-promoting, or wrap-around, >> should be the default? > > Ken, you are beating a dead horse on 1.3 numerics. No, I was just bringing it up as an example to illustrate something else. But now that you bring it up ... > In particular: (1) You think that the overflow defaulting choice is minor, > and I think it is fundamental. Actually, what I think is that the default (once you have a BigInt that is about as fast as a boxed Long when the numbers are small) should be to use BigInt except when primitives are specified, and to use checked primitive math then, with unchecked as an option. This would be most compatible with 1.2's numerics behavior, and still provide all 3 options for arithmetic handling. (I also have concerns about the *unchecked-math* flag I heard about somewhere. We can't have +, etc. testing some flag at runtime -- much less fetching a dynamic Var, which is a slow, slow ThreadLocal object at the JVM level -- before each add without losing performance badly. We really need an (unchecked-math (the-math-goes-here)) macro, or something, that affects what functions get used at *compile time* rather than a dynamic Var flag that is set before performing what you hope to be really fast math.) > (2) You were unaware of the platform issues > in Java that drove us to implement our own BigInt. That arose in connection with a problem with format, not a gripe with arithmetic. > That said, Ken's questions on numerics are not unwelcome. It is not > realistic for every comer to the mailing list to have encyclopedic knowledge > about what has gone before. That would be my category (3) above. :) > So nobody should bite anyone's head off for > asking a question that has been answered before (particularly if e.g. it is > hiding in a deep, convoluted thread and isn't search friendly). Which, unfortunately, is exactly what happened to me with the numerics thing a while back. :P -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- 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
