June 15, 2020

Monads and Transducers are Literally 100% The Same Thing

No Newsletter Next Week

I promised one last week but the Alloy workshop took way too much out of me. Since I'm doing another workshop next week, I'm just going to say there won't be a newsletter. Retrospective on the workshops will come after I've done both.

(Later this week I'll announce a late July TLA+ workshop. Stay tuned!)

"Are We Really Engineers" Talk This Friday

I'm speaking at 8th Light University on the differences between "traditional" engineering and software engineering. Link is here. I want to warn everybody that this is basically the first draft version of the talk. It'll be pretty unpolished and I will probably eliminate entire sections as I revise this more. But you might find it interesting nonetheless.

Blub Features

Something I've been thinking about based on a Twitter conversation last week. I made a joke about Rich Hickey that somehow turned into everybody discussing transducers. Many of the people, including me, didn't see why they were considered so hard to statically type, or what the advantages of them actually were. As one person put it, it always seemed that it was just like $thing except for some subtlety.

Then someone commented with this:

And it was like a bucket of cold water to me. A couple years back someone said that monads were basically "smart pipes", which made a lot of people really frustrated. They were frustrated that somebody without deep familiarity with monads was oversimplifying them, missing a lot of the nuance and subtlety. Yet I wasn't applying the same benefit-of-the-doubt to transducers. I didn't quite get them, so I sorta assumed they weren't that interesting. Which of is kind of a crappy approach, all things considered.

There's a parallel here between monads and transducers. They're both really valuable and expressive tools to the people that know how to use them, while outsiders don't really see the point. The difference was how much respect I was willing to give to the idea "I won't see the point until I 'get' it". This is very similar to the idea of a "blub" language, as originally proposed by Paul Graham:

When our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.¹

Now I strongly disagree with the rest of the essay. It's condescending, I don't think languages fall into neat tiers of power, and I think Graham is showing his own biases when he says that the most powerful language is lisp.² But I like the core idea here: that it's hard for us to see the benefits of things without having a reference point. Something like higher-order functions is easy to showcase the value of because we could compare it to a for loop. But monads and transducers are further from "mainstream" programming, so it's harder for us to make the benefits intuitive. The best we can currently do is just convince people to use them enough to see the benefits for themselves.

I say currently because this is something addressable through better teaching. That's been a lot of my work on formal methods. Things like TLA+ and Alloy are very far outside the purview of most programmers, leading to me getting responses like "I'd just write unit tests" or "That's Big Design Up Front" But I put a lot of work into showing how these things give you completely new benefits in ways that are tangible to programmers. I don't think this solves the blub problem by making people see the power. I think it's more likely that it makes people accept that if they studied this, then they will see the power. A sort of second-tier way of thinking: "I don't believe X, but I know I will believe it in two weeks." Which is wholly different from just directly believing X and it may be easier to persuade people that way.

But it might be possible to also just directly address things and show people why things are useful intuitively. I suspect we could do this with transducers by visually diagramming how the transducer operates with like six maps and three filters over a list, versus the visual diagram of not using the transducer. Times like this I wish I had art skills or any experience with making visualizations in JavaScript.

What are some other blub features? Rank in APL. Proper module systems. Fuzzing. Chapel's config keyword seems like one, but maybe the benefits are obvious enough that it's not actually blub. Function sets in TLA+. Predicate clauses.⁴ Inheritable contracts? I feel it's hard to tell what's the blub and what's just genuinely useful without seeing a lot of outsiders bounce off it. That's why it's so easy to identify both monads and transducers as blub.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.