Hi Gary, Re the documentation: A lot of people have worked to make clojure.org better, including changing the contribution model to be both easier and more familiar.
That said, I don't doubt that is could be a lot better. In particular, the guides section could expand to cover a lot of the "convention"-type topics you allude to. You can contribute here: https://github.com/clojure/clojure-site. And now also here: https://github.com/clojure/clojurescript-site. Stu On Thu, Aug 25, 2016 at 11:54 AM, Gary Trakhman <gary.trakh...@gmail.com> wrote: > 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. > -- 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.
