> Back at ya. I respect your opinion - I just see things differently. I think that is the perfect way to end this conversation :-).
On 8 November 2016 at 16:17, Alex Miller <a...@puredanger.com> wrote: > > On Tuesday, November 8, 2016 at 9:34:53 AM UTC-6, Colin Yates wrote: >> >> you mean Java with the 'billion dollar mistake' known as null? > > > Yep, that one, which millions of programmers use every day. > >> >> The Java which has just completed changed its Date and Time API _for the >> better_? > > > They did not "completely change" the API. They embarked on a lengthy (other > process issues involved of course) process that created a new *additive* API > with carefully considered integrations with the prior API(s). Every aspect > of the "old" API continues to work. > >> >> Or maybe you are referring to JavaScript with its insane >> scoping rules? Maybe Ruby with its ridiculously wide scoping rules? >> And I am pretty sure Java has and will continue to use the deprecated >> tag more than once. > > > Yes, but they also continue to NOT remove the deprecated parts, avoiding > breaking existing code. We have no plans to removed the deprecated parts of > Clojure either. > >> >> NEW languages are exciting precisely (or at least mainly) because they >> offer the opportunity to do things better, to evolve and learn from >> the past > > > Absolutely. But Clojure is no longer a new language and has 10ks of existing > users. There is only a narrow period of time where a language has the > latitude to change in significant breaking ways and I think we are past that > time for Clojure. > >> >> - legacy debt is by definition only legacy. I am not sure you >> are really suggesting that continuing to pay for a mistake _for ever_ >> is better than paying the cost of change once? > > > I think you are under-estimating the costs of change and over-estimating the > value of seeking perfection. > > I don't even believe that there is some "right" answer to questions of > language. Choices of language are inherently dependent on context (of the > language, of the designer, of the users, of history, of meaning) and there > are too many constraints for any set of words to perfectly convey a large > set of concepts. So, there will inevitably be function names that do not > seem right to you, or do not seem in sync with all other semantically > similar words in the other set of functions. I don't agree with every choice > Rich has made and we have wide-ranging disagreements about things like this > constantly. That's ok, I still like Clojure and in hindsight, the majority > of his choices are either better or unimportantly different. > >> >> Taking your argument literally we are only going to continue to see >> languages emerge to excitement only to then crumble under previous >> design decisions. > > > To some degree, yes. Personally, I still find Clojure to be the most fun, > productive, and useful language I have ever used. I do not have the hubris > to believe that it is perfect. But I'll take fun and productive over perfect > every day. > >> >> People make mistakes, new realities emerge, why on >> earth would you want to prevent the opportunity to upgrade? > > > Because there is tremendous utility in stability. > >> >> Unless I am mistaken any? was only introduced in the Clojure 9 alpha >> so comparing this to the stability of the Java APIs (which are in some >> parts horrendous to work with, purely because of legacy) is a bit of a >> straw man. > > > I'm talking in broader terms than just about any?. But re any?, see the > language comments above. I think "any?" is exactly the best word for this > case re spec (note that it's the same word used by both Schema and Herbert). > It's not the best word in relation to other existing functions. I do not see > this as the end of the world. > >> >> I entirely agree with your upgraded definition of 'good', I am not >> sure I buy the size of the constraint you mention (changing an API >> introduced whilst in alpha). >> >> Don't get me wrong, I am no Rich Hickey or Brian Goetz, and I highly >> rate Clojure and the design decisions behind it. Watching a number of >> Rich Hickey videos was like a breath of fresh air with a bunch of >> "yes, that is the nagging feeling I haven't managed to articulate" >> light bulb moments, but everybody makes mistakes. >> >> I can see this getting a bit out of hand, I wrote some inflammatory >> stuff which you are responding to in absolute terms. I am pretty sure >> that were this discussion next to the magical water cooler we would be >> much more on the same page as I can't believe you mean what you typed >> :-). > > > Would be happy to have the same conversation over a beer at more leisure. :) > >> >> Peace. > > > Back at ya. I respect your opinion - I just see things differently. > > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
