After further consideration, I would like to back off the word: "abomination". I have strong opinions about code, and strong opinions about technical aspects of Midje, but I chose the wrong word in my original statement. The technical definitions of words do not matter as much as the connotations they carry in common parlance. I can see how my choice of wording here can be taken as a personal attack. And so for that, I do apologize, Brian. In the future I will attempt to use less loaded verbiage.
Timothy Baldridge On Thu, Aug 25, 2016 at 10:33 AM, Timothy Baldridge <tbaldri...@gmail.com> wrote: > >> 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) > -- “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.
