>> 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.
Yes, that was me. And since this seems to come up rather often I should probably address it. I scanned the archives and found the original statement I made: "I don't recommend Midje at all. Many of the framework's mocking facilities (such as providing) are abominations. You shouldn't go around mucking with functions and re-deffing them on the fly. It may look cute, but I've lost countless hours to bugs and unexpected behavior related to Midje. IMO, stay clear of that. " So to be clear, I called certain patterns in Midje: "abominations", not the library as a whole, and defiantly never you. And unfortunately I have to stand by characterization of these facilities. I strongly believe that new code evaluation semantics combined with mutation of var roots is a great way to add complexity to your testing suite. Changing var roots on-the-fly adds complexity that will come back to bite you when you add things like async calls and parallelism. Creating new evaluation semantics makes code impossible to read without fully understanding the interpreter of the DSL. What is executed first? What happens when? Who knows, it's a foreign language. But please don't take my statements as a personal attack. I have written a lot of bad code in my life, some of it is used daily by clojure programmers. I often do code reviews, and I may come across as abrasive when discussing a bit of ugly code, but I bear no ill-will to the programmer. The same applies here, I may strongly dislike aspects of Midje, but I can dislike someone's work without disliking them. So now I'm completely off topic for this thread, but since my statement back in 2014 keeps coming back time and again, I figured it was best to clarify my words. And Brian, if we ever are at a conference together, let's sit down and I'll buy us a drink (or two). It'll probably do us both good to get to know each other better. On Thu, Aug 25, 2016 at 9: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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
