The Road to Amazonka 2.0

Last month, Brendan Hay and I released the 2.0 version of Amazonka, the de facto but unofficial AWS SDK for Haskell. Before that, Amazonka had seen intermittent commits and some pretty major improvements, but hadn’t managed an actual release in about four years. Because of the lack of visible progress, more serious industrial users maintained private forks instead of contributing to the main repository. It took about two years of work to pick up what was left behind, triage all the open issues, make several necessary major improvements, and get the whole project back into a shippable state.

I believe that many open source ecosystems have projects like Amazonka: projects which are large, important to their ecosystem, and stuck. These are my notes about how to unstick such a project, using Amazonka as a case study. It’s a fair amount of work, but a surprising amount of help can come out of the woodwork, once someone makes the first move. That person could be you, and if it’s not you, then who’s it gonna be?

The Maddest My Code Made Anyone

I was lucky enough to grow up through the early 2000’s, during the golden age of Half-Life mods. Industry classics like Counter-Strike (CS) had just been invented, every month brought new mods to try, and files were too big to download on a dial-up connection so you’d leech them off a server at a big local LAN party. One of my personal favourites was Natural Selection (NS), a sci-fi marines-vs-aliens deal where one of the marine players had to command the others, RTS-style, from a command chair. If you’ve never heard of it before, this 2022 video review of NS will give you a sense of what it was like.

As Half-Life modding matured, some really interesting inventions appeared. MetaMod was a C++ framework that interposed itself between the server binary and the actual mod DLL, allowing you to inject custom behaviour into an existing mod. I didn’t understand enough C++ to write MetaMod plugins, but that didn’t matter: AMX Mod and later AMX Mod X let you write custom plugins using a simpler C-style language called Pawn (known back then as “Small”). This enabled an explosion of ways for operators to tweak their game servers: quality-of-life improvements for players, reserved player slots for members, and delightfully bonkers gameplay changes. I remember having my mind blown the first time I stumbled upon a game of CS with a class-based perks system, inspired by Warcraft 3, and that was just one instance of the creativity that came from the AMX(X) modding scenes.

And with the Half-Life-specific background covered, we are now ready to talk about NS: Combat and my gloriously dumb contribution to the AMXX world.

Monoids in the Category of...

The unfortunate meme phrase “a monad is just a monoid in the category of endofunctors, what’s the problem?” comes from two sources:

• The fact and most of the phrasing comes from Mac Lane’s Categories for the Working Mathematician, but
• “What’s the problem?” is a cheeky addition from a funny 2009 blog post: A Brief, Incomplete, and Mostly Wrong History of Programming Languages

The meme words have become an annoying blot on the fringes of the Haskell universe. Learning resources don’t mention it, the core Haskell community doesn’t like it because it adds little and spooks newcomers, and it’s completely unnecessary to understand it if you just want to write Haskell code. But it is interesting, and it pops up in enough cross-language programming communities that there’s still a lot of curiosity about the meme words. I wrote an explanation on reddit recently, it became my highest-voted comment overnight, and someone said that it deserved its own blog post. This is that post.

This is not a monad tutorial. You do not need to read this, especially if you’re new to Haskell. Do something more useful with your time. But if you will not be satisfied until you understand the meme words, let’s proceed. I’ll assume knowledge of categories, functors, and natural transformations.

Deriving Simple Recursive Functions

I used to teach Haskell to first-year university students, and many of them struggled to write their first recursive functions. It really isn’t obvious why you can solve a problem using the function you’re in the process of defining, and many students have difficulty making that leap. There is no shame in this. I remember taking a long time to grok proof-by-induction, which has a similar conceptual hurdle: how can you use a statement to prove itself?

Writing recursive functions requires a lot of tacit knowledge in selecting the recursion pattern to use, which variables to recurse over, etc. Recursion was not immediately obvious to industry professionals, either: I remember an errata card that came with TI Extended Basic for the Texas Instruments TI 99/4A which mentioned that later versions of the cartridge removed the ability for subprograms to call themselves, because they thought it was not useful and mostly done by accident.

I want to share a recipe that helped my students write their first recursive functions. There are three steps in this recipe:

1. Write out several related examples
2. Rewrite the examples in terms of each other
3. Introduce variables to generalise across all the examples.

Worked examples and some teaching advice after the jump.

Uniplate is a Traversal

While writing code to rewrite some Dhall syntax trees, I noticed a cool connection between the core uniplate operation and optics. This will be old news to advanced lens users, but I think it’s worth pointing out. The uniplate package’s original uniplate :: Uniplate a => a -> ([a], [a] -> a) is an early attempt at a “traversal” optic, properly expressed in lens by plate :: Plated a => Traversal' a a.