I already do that, but that doesn't help general masses of people who would benefit from consistent & intuitive language constructs.
On Nov 29, 5:57 pm, David Nolen <dnolen.li...@gmail.com> wrote: > But the facilities for what you want are already there. Define a more > generic > < and exclude the ones from core. > > I'm constantly excluding fns from core which have names I'd rather use > in my own source. > > David > > On Monday, November 29, 2010, Tim Robinson <tim.blacks...@gmail.com> wrote: > > huh? Making a change to the > function doesn't mean you *can't* write > > high performance data structures in Clojure. It just means, you *may* > > need to use a different fn name as opposed to the common one. > > Similarly I could simply use a different name to accomplish my own > > function that includes strings, but that's not the point. > > > The point is that the common name should benefit the common user (not > > typically the folks who appear in this group, but still representing > > 90+ percent of usage). Many people would benefit by having a cleaner > > easy-to-use intuitive language. i.e '=' works on strings, so why not > > '>' ? It's not like I don't get the benefits listed, but I think this > > group should also consider audiences outside the arena of expert > > language programmers (who are capable of making functions to suit > > their needs). IMHO. > > > On Nov 29, 1:23 pm, David Nolen <dnolen.li...@gmail.com> wrote: > >> On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson > >> <tim.blacks...@gmail.com>wrote: > > >> > I dunno, > > >> > Where is this arbitrary point people set where language improvements/ > >> > ease-of-use become less important than negligible performance impacts? > >> > I ran several benchmarks, with warm up and correct time measurements, > >> > and didn't get the impression the change was in anyway significant. > > >> Perhaps not significant to you. But to others it means that they can write > >> high performance data structures in Clojure itself that other people can > >> benefit from. To me that's far more compelling than convenient string > >> comparison operators. Consider the implementation of > >> gvec.clj:https://github.com/clojure/clojure/blob/master/src/clj/clojure/gvec.clj. > >> I > >> wonder what "negligible performance impact" you change would have on that? > > >> It might more sense to put what you're suggesting in clojure.string. > > >> David > > > -- > > 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 -- 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
