I am really really surprised Bellroy could afford to hire developers for their own store. I guess they are now much bigger than I thought? I watch them grow from an unknown brand that focus on slimming your wallet in the early 10s, to now I bump into people who have actually heard of used it. Or at least seen the online ads. Pretty amazing.
I remember Gwyneth Paltrow said something along the line moving away from Shopify was the biggest mistake she made with her online shop. I think that was before Pandemic and Shopify have improved a lot since then.
Which makes me wonder if it make sense for Bellroy to continue their path.
A recurring problem, somehow making it very easy to write code that deals with 1 thing from start. When time comes , somehow hard to write code that deals with N things.
I wonder how different the code would look if it was just written to deal with N things from the start.
I’m also not sure how far this code can go, if I have queries that depend on responses of preceding queries , how will my runAp_ give me this? It probably won’t.
always wondered where are http frameworks that just give me a batch of requests to deal with from the start.
> I have queries that depend on responses of preceding queries , how will my runAp_ give me this? It probably won’t.
It definitely won't, which is what I was trying to get at with the discussion of monads and data dependencies. Applicatives by definition cannot have one "effectful" computation depend on the result of another. You could do a large bunch of parallel work until you need to pass a result into a function that decides what additional work to perform, at which point you need a monad. More advanced frameworks like Haxl apparently make this distinction explicit, so your computation proceeds as a sequence of batched parallel options, combining as much work as possible.
> We want to build a structure that is essentially a syntax tree of the operations we want to perform.
A-a-and so we went from programming in Haskell to creating a new DSL, with an interpreter for it in Haskell, and programming in that DSL. Which kinda begs a question: you already have a perfectly serviceable programming language (i.e. Haskell) at hand; why not just use it?
This is a really good question. If you write all the queries directly in Haskell, you get an IO action which you can't inspect: all you can do is execute it and see what it does. It might make requests, it might repeat requests it didn't need to make, it could do literally anything else.
Other programming traditions also have this pattern of inventing minilanguages and interpreters for them; regular expressions are by far the most successful example. You could hand-roll string matching by writing your matching functions by hand, but it's often much easier to ask a regex library to run an interpreter over a string describing the pattern to match.
In Haskell, it's really cheap to invent data structures, so using the same language to describe the work is quite convenient. Laziness also means you almost never materialise the entire intermediate "work to be done" structure - you build little bits as the interpreter demands them. So it doesn't feel as heavyweight as an eDSL in some other language.
I love me some functional programming, and spend most of days happily immersed in F#, but when I see Haskell programmers casually discussing the lengths they’ll go to to avoid side-effects, I am always in awe. It’s like overhearing monks in the Middle Ages talking about their favorite techniques for copying the Bible by hand.
This seems like a cool article, but it isn't readable without Haskell background knowledge.
> For an intuition why this is true, consider that the constant functor Const r has an Applicative instance whenever r is a monoid, because pure stores a mempty value and (<*>) combines the held values with (<>). For a fun exercise, implement runAp_ in terms of runAp and Const.
12 comments
[ 2.9 ms ] story [ 30.6 ms ] threadI remember Gwyneth Paltrow said something along the line moving away from Shopify was the biggest mistake she made with her online shop. I think that was before Pandemic and Shopify have improved a lot since then.
Which makes me wonder if it make sense for Bellroy to continue their path.
I wonder how different the code would look if it was just written to deal with N things from the start.
I’m also not sure how far this code can go, if I have queries that depend on responses of preceding queries , how will my runAp_ give me this? It probably won’t.
always wondered where are http frameworks that just give me a batch of requests to deal with from the start.
It definitely won't, which is what I was trying to get at with the discussion of monads and data dependencies. Applicatives by definition cannot have one "effectful" computation depend on the result of another. You could do a large bunch of parallel work until you need to pass a result into a function that decides what additional work to perform, at which point you need a monad. More advanced frameworks like Haxl apparently make this distinction explicit, so your computation proceeds as a sequence of batched parallel options, combining as much work as possible.
A-a-and so we went from programming in Haskell to creating a new DSL, with an interpreter for it in Haskell, and programming in that DSL. Which kinda begs a question: you already have a perfectly serviceable programming language (i.e. Haskell) at hand; why not just use it?
Other programming traditions also have this pattern of inventing minilanguages and interpreters for them; regular expressions are by far the most successful example. You could hand-roll string matching by writing your matching functions by hand, but it's often much easier to ask a regex library to run an interpreter over a string describing the pattern to match.
In Haskell, it's really cheap to invent data structures, so using the same language to describe the work is quite convenient. Laziness also means you almost never materialise the entire intermediate "work to be done" structure - you build little bits as the interpreter demands them. So it doesn't feel as heavyweight as an eDSL in some other language.
Can you give an example of that happening?
> For an intuition why this is true, consider that the constant functor Const r has an Applicative instance whenever r is a monoid, because pure stores a mempty value and (<*>) combines the held values with (<>). For a fun exercise, implement runAp_ in terms of runAp and Const.
Really?