On Wed, Dec 15, 2010 at 1:11 AM, Michael Gardner <gardne...@gmail.com> wrote: > On Dec 14, 2010, at 11:22 PM, Ken Wesson wrote: > >> On Tue, Dec 14, 2010 at 10:37 PM, Michael Gardner <gardne...@gmail.com> >> wrote: >>> That's what archives are for >> >> Are you honestly suggesting I search the archives for every word of >> every thought that it ever occurs to me to post here? >> >> I don't have that kind of time and I doubt anyone else does. If anyone >> started to actually enforce such a rule, participation here would drop >> to practically zero overnight. > > That's a mighty fine straw man you have there. And how deftly you knock it > down!
How rude. It is not a straw man. People criticized me for not having read a thread that was posted before I came here but that happened to be relevant. There's simply no way I could have known about that thread unless I routinely searched the archive for everything that might be remotely tangentially related to anything I was considering posting, and if I did THAT I'd spend far more time searching the archive than doing anything else. Moreover, there's simply no way I could have known about your EXPECTATION that I'd have read that thread short of telepathy! Now please drop this. I have done nothing wrong nor have I been exceptionally lazy or indolent. I may have raised a topic you don't like and consider to have been discussed to death -- tough. Nobody's forcing you to respond, or even to read, topics you don't like. For example, I ignore the reams and reams of how-to-configure-emacs posts this list gets, since I don't use emacs and thus don't find that material interesting. I don't instead pop up every two or three posts in those threads complaining that this is a Clojure forum, not an Emacs forum, or remarking "gee, Emacs sure is hard to configure, why don't you just use normal software with a normal Mac/Windows UI like everybody else?". Surely you can do likewise with primitive-arithmetic threads if you dislike those. >>> Are you saying that simplifying existing code provides no benefit? >> >> If it breaks existing client code then yes. Simplifying internals >> without altering API semantics is generally a good thing; when the API >> semantics start changing, though, an unequivocal improvement becomes a >> tradeoff that might tip either way. >> >> Changing the behavior of arithmetic operators that are found in >> virtually every extant source file is going to have a very big >> downside in broken backward compatibility. If there's an upside, it >> would have to be staggeringly enormous to make such a change >> worthwhile. > > The claim I responded to was: "it cannot logically ever be a point against > keeping current behavior". You are now arguing a much weaker claim, that the > upside of simplifying existing code is unlikely to outweigh the drawbacks of > breaking existing code. No, I'm arguing a completely unrelated claim. I didn't consider my earlier claim to be in dispute, since it is pretty much self-evidently correct and you didn't subsequently address it. To be exact, I had said that "it's hard to implement" can be a reason against adding new behavior, but that it is never a reason not to keep the current behavior -- hard to implement or not, the current behavior is ALREADY implemented. You didn't remark upon that, but instead said that it could simplify the code internals. That's a separate matter from what's hard to implement. You're not talking implementing arithmetic from scratch but re-implementing it. Re-implementing it is, obviously, harder than not changing anything at all. So you're doing something harder-than-nothing and that breaks backwards compatibility. That requires a justification and I'm not sure "it makes the compiler/library source code simpler" is sufficient when the backwards compatibility breakage isn't just for some relatively infrequently used feature (such as, say, the changes to agent error handling a version or so ago) but is going to affect almost every application and library out there. Again, there'd have to be a staggering further benefit from the change than just "the clojure.core code looks cleaner in github" or even "the code is a bit easier to maintain in the future". I'm not sure that even massive increases in code maintainability alone suffice for something like this. A major, massively end-user-useful new feature that's nigh-impossible to implement otherwise that can then be implemented *might* suffice. -- 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
