Over the years I've kind of started agreeing with what Brian's saying. Much as I love/know clojure and the philosophy that bears its fruit, I think spec's sideband error-handling is a great low-risk opportunity to build in some 'easy'.
My team is moving from rails towards elixir after having seriously considered clojure (and hiring me recently under that premise), and I'm having to apologize for the general lack of novice guardrails, 'conventions' and documentation that people from other communities expect. I think it looks pretty good if you're used to java (java conservatism notwithstanding), but not so good if you've been in dynlangs (particularly ruby) or other FP languages besides lisp. I'm concerned the current approach will lead to too many half-baked error-reporters. Alternatively, if there's a canonical human-facing error-reporter built on top of the more stable data representation, I think it would be generally acceptable to break 'contracts' there as we find better ways to show the errors. On Thu, Aug 25, 2016 at 11:18 AM Brian Marick <mar...@roundingpegs.com> 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. > -- 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.
