Thanks, Adrian. I'm unsure about the disrespectful part - as I mentioned, discussions around community problems are always difficult, but they are important. As with all internet conversations, of course, tone is everything.
But since this is very well-trodden ground, and for whatever reason it's clear it won't change, I definitely agree they're unproductive. I'll be leaving the non-error-message aspects of this conversation alone now. On 26 August 2016 at 12:03, <adrian.med...@mail.yu.edu> wrote: > Colin, > > FWIW, I think you're doing a great job of articulating your points (which > I largely agree with) and are providing great feedback for the core team > and community to think about. This conversation is supposed to happen as > the alpha versions are being iterated on. > > But I think continually resurfacing meta issues one has with Clojure's > management (and I'm not saying you're doing this, but others are) instead > of engaging thoughtfully with a team who is engaging you thoughtfully is > both disrespectful and unproductive. Actually, it's counter productive > because it can unfortunately make people think twice before taking you > seriously in the future. > > Like you, I think friendly error messages is an important issue for > Clojure. We have an amazing source of heavily annotated information we can > use to generate best-in-class error messages thanks to clojure.spec. We > should refocus this in thread. > > But I'm not a moderator, so I guess take whatever I say with a grain of > salt. :) > > On Thursday, August 25, 2016 at 7:12:04 PM UTC-4, Colin Fleming wrote: >> >> I really don't understand how you expect anyone to take your criticism >>> seriously if you keep implying you're happily abandoning the language for >>> greener pastures. >>> Why would anyone developing Clojure look at anything you have to say at >>> this point as anything less than trolling? >> >> >> Because if we're genuinely interested in improving the language and the >> community around it, the people who are deliberately choosing to leave it >> have the answers to what we need to do that. >> >> I develop Cursive, and I'm always very interested in feedback from users, >> and I'm really *more* interested in feedback about what they don't like >> because my opportunities for improvement are there. It's always nice to >> hear that people love Cursive and those messages are an important part of >> maintaining my motivation to continue working on it. But in terms of >> feedback that I can directly action, problems are where it's at. >> >> Of course, sometimes that feedback is not useful, actionable or valuable. >> "IDEs suck" gets ignored, in much the same way that "Clojure sucks because >> it's dynamically typed" should. "I don't use it because I find IDE's too >> heavy" (like "I don't use Clojure because I prefer strong types") is fine, >> there are lots of people out there with different preferences and I can't >> cater to everyone. Being based on IntelliJ is what Cursive *is*, and I >> can't change that. But if someone uses Cursive a lot, likes it, talks >> publicly about how much they like it, participates in the issue tracker and >> on the mailing list etc etc but then says "I'm taking up Emacs because I >> can't stand how Cursive does x, y, and z" then I will absolutely try to >> make those things better. >> >> Criticisms about how the community works are perhaps the hardest to hear >> since they seem very personal - if we're active in the community, in some >> way they're directly criticising the ways we behave. Similarly, they're >> much harder to fix. But they are essential, since no-one uses a programming >> language purely because of the language itself these days. >> >> FWIW, I share many of Brian's concerns. >> >> On 26 August 2016 at 03:46, <adrian...@mail.yu.edu> wrote: >> >>> I really don't understand how you expect anyone to take your criticism >>> seriously if you keep implying you're happily abandoning the language for >>> greener pastures. >>> >>> Why would anyone developing Clojure look at anything you have to say at >>> this point as anything less than trolling? >>> >>> Back on topic, I find Colin's suggestions about implementing an error >>> reporting heuristic intriguing. What he has laid out could form the basis >>> for a solution to this problem which can satisfy everyone's requirements >>> when integrated well with spec's explain-data. I am curious to hear what >>> Alex and others think about it. >>> >>> On Thursday, August 25, 2016 at 11:18:28 AM UTC-4, Brian Marick wrote: >>> >>>> >>>> On Aug 24, 2016, at 9:28 PM, adrian...@mail.yu.edu wrote: >>>> >>>> I do not think your tone and lack of constructive feedback to Alex's >>>> (and others) thoughtful responses is helping your case. >>>> >>>> >>>> Probably not(*), though I would characterize the responses differently. >>>> They are polite, and they are intended to be helpful to someone who already >>>> agrees with axioms like “good error-handling is a nail for which core.spec >>>> is the hammer” and “it is wise to push the responsibility for error >>>> understanding to third-party libraries or diligent study”. They do a >>>> service in that they lay out the rules under which Clojure users should >>>> expect to live. But they are largely reiterations rather than engagement. I >>>> find that rather frustrating. >>>> >>>> >>>> Let me point to an essential book on business/community management, >>>> Hirschman’s /Exit, Voice, and Loyalty/. https://en.wikipedia >>>> .org/wiki/Exit,_Voice,_and_Loyalty, and to a clever take on group >>>> behavior, “Evaporative Cooling of Group Beliefs”, http://lesswrong.com >>>> /lw/lr/evaporative_cooling_of_group_beliefs/. I think there is much to >>>> learn from reflecting on those and the direction of Clojure design and the >>>> Clojure community over the past few years. (I’m not a huge fan of the >>>> application of Satir’s family counseling theory to software management - >>>> Gerald Weinberg and the like - but it’s hard not to read books like the >>>> /Quality Software Management/ series and see people in the Clojure >>>> community - including me! - playing out stereotypical dysfunctional roles.) >>>> >>>> Read me as someone who’s publicly and self-destructively giving up on >>>> Voice and is on the way to Exit. As someone who tends to Loyalty (though >>>> perhaps the loyalty of the traditional Catholic Devil’s Advocate), it’s >>>> rather agonizing. That is, I still think Clojure is the best raw language >>>> out there for broad-spectrum work. However, its design has been doubling >>>> down on long-unfortunate tendencies, and - I’d argue - new languages like >>>> Rust, Elixir, and Elm (even Pony) - are raising the bar for both community >>>> management and “peripheral” concerns like documentation and error handling. >>>> In the meantime, the Clojure ideology - reinforced by memes like >>>> “complecting” - has been getting more rigid. >>>> >>>> The result is that what seem to me bizarre decisions are treated as >>>> normal. We have an `any?` in clojure.core that always returns `true`. This >>>> deviance from probably every other programming language is justified as >>>> obvious for a feature - clojure.spec - that is largely unproven, certainly >>>> when it comes to error reporting. (Even worse, we have `any?`, `some?`, and >>>> `some` - all idiosyncratic.) Yet the idea of changing the name of `any?` is >>>> completely dismissed, with the justification that people complain about >>>> every new name. (Think about what that decision criterion entails, broadly >>>> applied.) >>>> >>>> Also bizarre: the idea that error messages that amount to essentially >>>> dumping a parse tree + BNF-ish grammar clause (possibly twice with a >>>> vomitous stack trace between) is a *good* thing. Not a “we wish we could do >>>> better, but software development is about constraints and tradeoffs” thing. >>>> Not a “yeah, but Rich Hickey doesn’t want to bother with that stuff” thing. >>>> >>>> (I was honestly flummoxed that, although clojure.spec is supposed to be >>>> the answer for error handling, there’s been no attempt to work through what >>>> good error messages would be like and how the current infrastructure would >>>> support the translation from raw data to such error messages.) >>>> >>>> I cannot help but think of this as groupthink. And - to be grandiose - >>>> having people like me Exit will increase that, per evaporative cooling. >>>> >>>> >>>> I also note that my library, Midje, is typically insulted on this >>>> mailing list whenever a newbie brings it up. One of the contributors to >>>> this thread has called it “an abomination”. There was no similar concern >>>> about *his* tone. Because, I suspect, he's on the inside, punching out. >>>> >>>> --- >>>> >>>> (*) Might that not be my fiendish plan? Perhaps I’m being abrasive on >>>> this list exactly to associate ideas like “error messages are the >>>> responsibility of the compiler” as being from a hated Other, thus hardening >>>> a position that I think is bad for Clojure. Why would I do that? Because >>>> I’m 90% likely to be going all-in on Elixir and Elm. Encouraging >>>> destructive behavior in a competitor language increases my languages' >>>> chances of success. Bwahaha! (Oops, just violated rules 6 and 7 of >>>> http://www.eviloverlord.com/lists/overlord.html ) >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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+u...@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+u...@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. > -- 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.
