Free applicatives, the handle pattern, and remote systems

The second-to-last post[0] talks about how they decided to migrate their stack from Ruby on Rails to Haskell, and are now in the seventh (!) year of that migration.

[0] https://exploring-better-ways.bellroy.com/designing-for-the-...

I'm very happy with my Bellroy Card Sleeve wallet. You know, just in case anyone's checking the comments on a functional programming article for wallet recs. As one does.

And they even use Nix, to add to the craziness.

[0] https://flox.dev/nixinthewild/nix-in-the-wild-bellroy/

Also was surprised to see their logo on the blog website.

I have had one of their cardholders for 10 years now, it is incredible how durable and practical that thing is.

So is Costar, the horoscope app, of all things

I thought this was a joke about two things having the same name… nope!

One funny thing about software is that beautiful things can emerge from the most unexpected places. I appreciate that there are folks out there with the bravery to share their journey.

They must be making a lot of money!

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.

Creating specialized and constrained DSLs is a common and useful pattern for folks that write Haskell (or really any FP lang that has ADTs).

I don't understand your complain. Haskell is entirely aimed at creating those small languages and interpreting them. While at the same time the compiler they have in hand implements a DSL for describing imperative programs that do not allow the kind of analysis the author is doing.

What exactly you expected them do write?

That's what I also don't quite get. I would build it as the parsing step mapped directly over the query. I suppose their approach lets them build a tree of operations but I'm skeptical it provides all that much benefit.

> 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.

I believe this is a case of “developers who went into the wallet business”, actually.