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 <javascript:>> 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 >> <javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> 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.
