The middleware pattern

Why is it so hard to describe to new people? I mean, the questions I get are (I understand what's happening here, but I can't describe it well): 1. If -> threads things first-to-last, why does the middleware run last-to-first? 2. Why is comp backwards? 3. Wait, so how does each wrapper get a

Re: The middleware pattern

To follow up on middleware, this is a great picture to demonstrate it. 687474703a2f2f692e737461636b2e696d6775722e636f6d2f68623864422e706e67 On Fri,

Re: The middleware pattern

Could you use Russian Dolls as an analogy? To build a Russian doll (or to build middleware) you start out with the smallest doll, and put it inside the second smallest, which in turn goes inside the third smallest. When opening the doll (calling the function) you start with the largest doll,

Re: The middleware pattern

@Raymond I like the illustration a lot. Perhaps I will use something like this. @Marc I think this would likely be like "monad burritos"... it makes sense to people who understand it in the first place. Although, I noticed when trying to explain it today, that I had a concept of "size" in my

Re: The middleware pattern

comp isn't backwards, it's just "outside-in". ((comp not zero?) x) == (not (zero x)) So it reads in the same order from left-to-right as it would otherwise. On Friday, October 2, 2015 at 1:10:54 PM UTC-6, Jason Felice wrote: > > Why is it so hard to describe to new people? > > I mean, the

Re: The middleware pattern

@Matthew It also follows the dot notation for function composition, right? This makes sense, but then: (def iso8601->timestamp (comp date-time->timestamp iso8601->date-time)) On Fri, Oct 2, 2015 at 5:39 PM, Matthew Boston wrote: > comp isn't backwards, it's just