I certainly from time to time have to rewrite some comparator for strings for GUI stuff (sort by label, etc.).
Even there, sometimes I need to sort without caring about capital letters, sometimes I don't need ... But indeed having some ready to use string comparators in a str package could be interesting. 2010/11/30 Tim Robinson <[email protected]> > 2. I agree with having both. > > 3. Lol. I love that you asked your wife and kids.... that's where I > always go. > > However, I don't think they represent a reasonable audience. When I > say the general masses for intuition, I'm speaking about the average > programmer whom reasonably would want to compare things that > programmers typically compare: ie. to handle stepping through > alphabetical names dynamically, or date-strings checks. It's not like > you couldn't do a google search on how to compare datestrings in Java > or Clojure and not find a bunch of Question/Answers addressing such. > > Just my 2 cents. > > The notion or > < being used to handle string comparisons is not > foreign to programming languages, using them for the examples you > provided are. > > > > On Nov 29, 7:40 pm, Stuart Halloway <[email protected]> wrote: > > Reasonable people can certainly disagree here, but to elaborate on my > earlier reply: > > > > 1. If you provide only a primitive feature, and users want a compound, > they can always create it for themselves. On the other hand, if you provide > only a compound, and the user wants the primitive, then they are screwed. So > if you are doing only one, the answer, IMO, is clear. > > > > 2. That said, one could have both, e.g. math/> and polymorphic/>. Whether > this is a good idea might be explored through community experience. > Namespaces let you have both and use whichever one you prefer unadorned, and > contrib provides a place to give it a try. > > > > 3. The appeal to intuition is perilous. I just explained the notion of a > string of characters to my wife and daughter (who are not programmers) and > asked them if they thought > or < was meaningful for strings. They answered > "Of course!" and followed with some examples: > > > > ;; anybody knows this! > > (< "seven" "eight") > > > > ;; specificity > > (< "green" "mint") > > > > ;; excellence > > (< "poor" "good" "great") > > > > ;; descriptive uniqueness > > (< "hattie" "the quick brown fox") > > > > One of the first things they said was "Of course < and > of strings is > only meaningful in context." > > > > Stu > > > > > 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 <[email protected]> wrote: > > >> On Mon, Nov 29, 2010 at 2:28 PM, Tim Robinson < > [email protected]>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 [email protected] > > > Note that posts from new members are moderated - please be patient with > your first post. > > > To unsubscribe from this group, send email to > > > [email protected]<clojure%[email protected]> > > > 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 [email protected] > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > [email protected]<clojure%[email protected]> > 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 [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
