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 <stuart.hallo...@gmail.com> 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 <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
