Brian, your concerns have been heard. Please keep in mind this is a work in progress and that there is ongoing work that is not yet visible.
While I don't expect that the final endpoint of this work will be exactly what you would design (or what you might see in other languages as our goals and priorities are different), I do think it will be better than it is now and vastly better than before spec existed. I do not think you are a "hated Other". I welcome your contributions to the community. As a moderator of this list, I do not recall seeing the "abomination" comment on the mailing list, but I agree that that is inappropriate and unwelcome here. Disagreement is fine, disrespect is not. I regularly address comments like this either privately or publicly (depending on the situation) and I'm sorry I missed that one, so I apologize for that. On Thursday, August 25, 2016 at 10:18:28 AM UTC-5, Brian Marick wrote: > > > On Aug 24, 2016, at 9:28 PM, adrian.med...@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 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.
