Providing documentation for open source projects is a necessary support activity for any library author, but it comes with a heavy maintenance cost, particularly for large projects.

In my experience, a team of one or two developers cannot sustain the maintenance of documentation for even one large library or framework, let alone two or three or four, as we do today.

My goal with this post is to share an idea with our fellow open source library maintainers, a notion I've come to think of as 'Example Driven Documentation'. There will be a lot of references to the implementation of this idea that we now use via an open source internal tool called 'Purpledoc', but it's the idea that I want to offer up for consideration.

People typically write documentation containing code examples, but what are the maintenance implications of flipping that around, and having code examples that happen to contain documentation?

In this video tutorial, we'll build a version of the classic game 'Snake!', from scratch.

Indigo and Tyrian are both based on flavours of the Elm architecture; But why that architecture pattern, and how does it work?

In this post, we define some desired principles of how we'd like to program a Graphical User Interface (GUI), and watch the Elm architecture's API inevitably emerge.

It's 2024! Yes, I know we're well into Feburary by now... but did you make any new years resolutions?

One of my resolutions from last year, was to work up the nerve to do another Scala meet-up talk on Indigo. The last time I did one ('Functional Game Programming') was in the heady days of pre-pandemic 2020, and a lot has happened since then, both in terms of Indigo's development, and the Scala community in general.