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