Forem: druchan

500 days of rdigest

druchan — Sat, 07 Mar 2026 06:30:00 +0000

rdigest is a small CLI-based tool I made in late 2024. It began as a way to manage my daily reading (online digital consumption) because YouTube's UI was distracting, RSS feed readers and their infinitely-scrolling pages were overwhelming and I had cut out social media from life eons ago. TL;DR, digital content consumption was at some unmanageable crossroads in life and I had to find a way to deal with it.

I've been using rdigest for 500+ days now. Of the handful of side-projects I built to scratch my own itch, this remains a powerful daily-driver.

I.

Now, this part about what rdigest is (and why) is for the accidental reader who landed here god knows how:

rdigest is technically a feed reader but it's also not really a feed reader. It collects links from all the feeds you follow and then creates a daily digest for you. The daily digest is just a finite bunch of links. A bunch of links grouped by source and zero algorithm. A bunch of links you look at, skim through, click on the ones you want to actually read or view... and then you're done with your digital content catch up!

That last bit is the critical piece, the linchpin ideology.

The way we consume digital content today is horrible. There's an infinite, never-ending stream hitting at us at all times. All kinds of platforms have interfaces that are designed cunningly to trick your brain into staying on the platform for as long as possible. You're thinking about Twitter, Instagram, TikTok and YouTube, but even other outlets like blogging engines, content management systems, AT-Proto interfaces (Mastodon/Bluesky) and even popular feed readers promote and enable these "infinite stream" interfaces.

This leads to all kinds of problems. Attention is low, ability to sustain a longform is gone, and no interface or product gives you this feeling of closure. The same mechanics of constant connectivity over work Slack ruining work-life boundaries are at play: it never feels like you're done reading, seeing, hearing the things you want to for a given day.

Alright, so that's the tirade against dark-pattern-embracing products streaming endless content and hacking into our neurons.

There may be many antidotes to this. rdigest's idea is borrowed from the old, physical newspaper model that I harp about. Imagine the morning newspaper (ie, if you're old enough). The paper arrives. You skim through the headlines, read the ones that interest you, and then you're done for the day. There's nothing more to do there (unless you were some hotshot that got the evening paper too). rdigest pretty much does the same, except it is about links from RSS feeds you follow and it's got no frills. Just a page of links like this:

II.

Reminiscing about a "hand-written" side-project in the age of LLM-written software seems weird and futile. There's nothing special anymore about building software except for the big picture bits and the devil-is-in-the-details bits.

And yet, artisanal software, especially of the crude, home-cooked kind might retain its charm.

I had two hopes when I began rdigest. One, to build something that eventually helps me manage my daily digital consumption (that had spiralled out of control to the point of giving up on online reading). Two, to learn a programming language (Haskell in this case) along the way.

I kept a journal while I built rdigest. The first entry goes:

Decided to finally build something in Haskell to learn the language. So far, I've been solving puzzles and similar tasks, but nothing has given me the confidence to say, "Yes, I can build that in Haskell."

As I built out rdigest, I ended up learning nuanced things about file I/O, batched concurrency, safely interacting with SQLite, implementing a small migration module, and more, all from within the Haskell ecosystem. Like all side-projects, it was fun, it was frustrating at times, and thankfully it also ended up being rewarding.

III.

Work on rdigest began in late 2024. By this time, I was using ChatGPT at work as an intelligent rubber-duck that talks back. Whatever I'd have googled or Stack Overflowed, I ChatGPT'd.

rdigest was built by hand but definitely helped by inputs from ChatGPT. Of course there were also many instances when the LLM sent me on wild goose-chases and proffered irrelevant complexities.

Wrote some initial code based on ChatGPT's example of scraping. However, ChatGPT got the attr function wrong.

ChatGPT suggested optparse-applicative, but I decided it was overkill for what I needed. A simple --url <url> argument was enough.

I had a long chat with ChatGPT about these things, asking it about the idea of bubbling up the errors from ExceptT without having to do runExceptT wherever I wanted the error to be bubbled up but the ideas it returned were not working or not useful — or in some cases, it was just reinventing the ExceptT or ReaderT monad transformers.

But also:

... I learned how to bundle the template as part of the binary by inlining/embedding it using the file-embed package—all of this thanks to ChatGPT.

Asked ChatGPT for a good web scraping library in Haskell. It suggested tagsoup and html-conduit (for fetching the source). Took a look at the examples and docs... seemed a little hard to grasp. Asked ChatGPT for a simpler alternative, and it suggested scalpel. Liked it, and decided to use it.

Claude had not yet come up as a significant competitor. Today, I don't use ChatGPT almost ever.

IV.

For a very long time — ie, over a year — rdigest remained a CLI-only tool. The only way to add feeds, manage them, produce a daily digest, and so on was to use the tool in a terminal.

But right there on my day 1 journal entry, I had wanted to also make rdigest spin up a local server so that the feeds could be managed and daily digests could be viewed on a browser.

Life got in the way. I would occasionally push an update or two. I even built a now-defunct feature that sent the daily digest links via Telegram. But the server feature never happened.

I finally managed to find some motivation to build out this feature in the last week. What's special about this is the stack: the heavy-lifting backend, server and CLI are all in Haskell, a pure functional language, and the frontend application that renders a near-brutalist, minimal web interface is written in Elm, a pure functional language inspired by Haskell. There was a brief moment where I considered htmx, but chose Elm eventually.

The local server feature is not something I use every day. I have a different setup to make the daily digests available "on the cloud" so I can view them no matter where I am, even if I don't have my laptop. In retrospect, maybe this was the friction that kept me from building the local-server feature; I didnt really need it.

But, like my other project vāk where I keep wobbling between "make this usable for everyone" and "just build things for myself", the thrust for rdigest's local-server feature comes from wanting to make this tool easier to use for others as well. You know, just in case. The odds of someone using it are lower than the odds of a comet striking our planet in the next fifty years. But just in case.

V.

Work on rdigest happens sporadically. The commit history says I worked on it for a few concerted days in Jan 2025, then March 2025, then a big sabbatical till November 2025 and then now in March 2026. Big periods of inactivity, small chunks of moderately intense activity. Basically, the tale of every other side-project that gets used routinely.

This pattern repeats itself in vāk too, and then also on my toy npx-powered game wordladder.

It's worth talking about because going back to these projects after a long hiatus does not involve broken builds or security conflagration or fuzzy/messy recollection of the modules/functions... you know, the kind of things you'd expect in projects built in weak languages unfortunately powering the world.

Instead, there's clarity, assurance, and guarantee. I attribute most of this to the semantics of the languages. vāk and wordladder use PureScript (a Haskell-inspired language targeting Node/JS environments). rdigest uses Haskell and Elm. Changes and even massive refactors are not scary.

So yeah. 500 days of rdigest.

I know. All you've been thinking of is, "the project needs a better name."

Going back to the morning newspaper model

druchan — Mon, 02 Mar 2026 06:30:00 +0000

Recently, Current RSS reader hit the headlines and I had a gander at what it is, how it's designed and what the underlying philosophy is.

It's a beautiful-looking app. But the fundamentals are problematic and repeat the same mistakes that lead to different kinds of problems you and I face w.r.t. digital content overwhelm as we try to grapple with, catch up on, and manage our digital consumption.

I. We consume about a fraction of what hits our streams

For many years now RSS feeds have been a boon as social media and YouTube took over the digital content landscape. But as the maker of the Current RSS reader points out, the email inbox-style design has added a subconscious anxiety to managing RSS feeds too. Why do we need an unread count?

When you are subscribed to a few hundred feeds, the amount of links staring at you is huge. But, and here's the obvious thing, we actually are interested in, on a rough average, about 20% of things out of that list. It makes no sense to have an anxiety-inducing user-interface that says you have 1438 unread links. You probably care only to read about 20-30 of them today.

But this is not the only problem. This is not even the key problem.

II. "Streams" are problematic, and they are using it to hack our behavior.

In my W.I.P. guide/booklet, Escape from Algotraz, I talk about this fundamental issue about social media "feeds". They are an infinite stream. Never-ending. The more you scroll, the more it keeps scrolling.

This is one of the darkest design patterns we've cooked up. If you grew up in the older internet, you remember hitting the end of a paginated list of items. There used to be an end to things. Now there isn't. It's not an eventuality.

Despite there being an infinite amount of content to consume, apps can decide to "end" the list of items for you. They can choose to say, "oh that's it for now, come back and check in a few hours, we'll show you new content." But they won't.

RSS feeds are limited by the number of feeds you're subscribed to but they still manage to stream an almost infinite-looking stream at you. Couple that with the unread count and you're back to anxiety-town about unmanageable digital content consumption.

Apps like Current RSS reader (which literally uses the word "river" for the stream of content from your feeds) are merely reinforcing this bad pattern. Smart removal of items from the feed is not going to solve the fundamental issue (and it only introduces more cognitive load for us).

We do not want streams. Our brains are not wired to process streams. They need a break and, if the designers and developers care, apps can be designed this other way.

III. Our brains are good with batch processing.

Have you ever done this thing where you said to yourself that you'll catch up on the unread items over the weekend? Or that you'll do all the chores (cleaning, laundry, meal prep) over the weekend?

We're essentially "batching". Turns out batching is a good antidote to "streams".

Here's another analogy. This one works for folks who grew up with physical newspapers around. Do you remember getting the morning newspaper, skimming through the headlines and reading a few of the news items in detail? What after that? We were done. That's it. Even if you went back to read some more, there was this palpable feeling of being "done". A closure of sorts. Task = done.

The digital user interface landscape today is designed specifically to prevent you from feeling this way.

IV. The onus is on ourselves to fix this for us.

I couldn't find an app that did this for me and worse, I couldn't find literature around this either. While there's so much brouhaha about calm technology, when it comes to content overwhelm, it seems the onus is on us, the users, to find out a way to fix it.

So I started experimenting with ways to manage my content (and discovering, inculcating and testing the underlying philosophical argument). Eventually, I managed to write up a simple solution: every day, I produce a plain HTML page of links from all my feed sources. With my 300+ feed subscriptions, I get about 400 links on average. Of this, I am only interested in about 10-20% on average.

This plain HTML page is my newspaper equivalent. While I do read news elsewhere, this "digest" happens to be my way of batch processing my daily content I want to keep tabs on.

And it has worked fabulously well for about 500 days now. In the morning, I open my digest, and open the links that I am interested in (a combination of news items, op-eds, LettersOfNote-like pieces, stuff from Hacker News/Lobsters, Veritasium-like YouTube videos, some cooking channels, some chess channels, parody or satirical content etc.). And then, if I have time in the morning, finish reading most of it before work, or read them in bits and pieces through the day.

Most importantly, I know this is all I want to read for the day. There may be an occasional 2-3 extra things I consume (someone shared a link on WhatsApp; I accidentally opened social media; links from email).

At the basic level, why this has worked well for me is the mental perception. My digest gives me a finite list of content to work through. Out of this finite list, I am interested in a fraction. It's all ridiculously manageable.

The fact that we're only interested in a small fraction of content should be so obvious, right? But try that with an infinite stream of content. A fraction of infinity still feels like infinity. But with finite content — as in a digest or a newspaper — you realise the manageability instantly.

V. "How we got here" is clear. And so is "how to get out of here?"

I am convinced that an entire class of problems is solved if the interface lends itself to reminding us of the finiteness of content and time. (Look no further than the "inbox zero" trend. The idea was to create finite chunks out of an infinite stream, so that you can then manage that finite chunk easily while also having the (false) feeling of having cleared everything.)

Eschew streams.

Create interfaces (or pick those) that have a finiteness to them. No infinitely scrolling interfaces. No constantly streaming screens. Just simple plain pages that start and end and when they end, it's a nice little reminder that you are done for the day and can go back to other things in life.

If we want to go back to a healthier digital content consumption era, we might just need to use the principles of older interfaces going back to the newspaper era.

P.S.: I didn't want to make this a plug for my solution so I am linking to the open-source codebase here: rdigest. The app doesn't matter; what matters is the underlying principle of design that I've written about above and that's something almost anyone can now mimic with the advent of AI/LLMs.

One year of vāk

druchan — Sat, 07 Feb 2026 06:30:00 +0000

Some time back, in a routine cleanup of my many drafts, I found one where I "introduced" vāk, the blogging script/tool I use to run my blog. I never quite finished that draft. I am certain I must've dissuaded myself from writing it by thinking, "no one's going to read it anyway."

About a couple of days back, I introduced a new feature to vāk: collections. Collections is just "tags" in some other shape. Testing this new feature is how I stumbled on the old, unfinished draft introducing my custom blogging tool.

This then led to checking the earliest commit in vāk's repo:

commit a19750ed19c1e4fd684092b7a7be6b263a3d7038
Author: Chandru <...>
Date: Fri Feb 7 18:49:37 2025 +0530

    init commit

That is about a year ago. Calls for some kind of a small celebration.

But in truth, vāk predates this timeline. The contents of my blog and the tool existed in the same repo. Feb 7, 2025 is the date I separated the tool (vāk) from the blog (this one) and initialised a new repo for the tool. Checking the earliest commit on the blog itself, back when vāk was still a part of it:

commit 244434366b7f5b11c0850041b52c50345e447ce9
Author: Chandru <...>
Date: Fri May 12 16:23:53 2023 +0530

    Init commit.

That's almost 3 years ago.

In keeping with the mores of my time in the 2000s, I set up my first blog on Blogger.com. I might've set up a few in haste and deleted all of them (in haste too). When I had much to write about, like the journals during my first stint in Ahmedabad, I set up a blog on Tumblr. Then, back in Chennai, I set up a new one, on WordPress this time. This was also the time when I attended a blogger's meet conducted by IndiBlogger. At approximately 4-5 posts a month on average, I published about 50 posts on the WordPress blog before retiring it (I have no idea why) and resuming my writing on Tumblr.

Tumblr was a go-to whenever I needed a blog or a website to put something up. I had gotten used to its theming (which was just CSS wrangling). It was just way too easy to set up and run.

Until finally, I decided that as a programmer, it would be nice to have a blogging tool built by hand. Might've been the rite of passage thing.

Around this time, I was trying to learn Haskell and PureScript. My blog posts were going to be simple Markdown files and I knew it was trivial to convert Markdown content into HTML content using JS libraries. PureScript offers a really simple and easy FFI so I started building out vāk in PureScript.

Those initial commits (3 years ago) started as a .purs script that fetched all my posts from Tumblr (via an API) and rewrote them as Markdown files, because at the time, Tumblr's API returned an HTML version of the posts.

Then, I wrote a bunch of functions that generally converted a given Markdown file into an HTML file. The reason for this roundabout was because future posts were going to be written in Markdown.

A few iterations later, broad contours of the system were ready. I had one repo to rule them all: the blog, the content, the published website etc.

About a year ago, I split the tool into it's own repo and called it vāk. (Why vāk?).

In the years since, there have been only two major upgrades to vāk besides the usual and infrequent tweaks and clean-ups.

The first is an internal detail. I used something called monad transformers to create better abstractions to run functions and catch errors.

The second is making the templates very customisable by relying on the Nunjucks templating engine. This came about as a continuation of my unnecessary effort to make vāk a tool anyone can use.

In a strongly-typed functional language, changes are a delight to make. I often employ this idea called type-driven design; it's like sketching out the app (or feature) on a wireframe of types before implementing the functions that do the thing.

I picked up a few PureScript/Haskell skills along the way. Prior to working on vāk, I kept away from monad transformers and hadn't really worked with concurrency. I hadn't architected anything larger than a script that solved LeetCode problems. Building vāk on PureScript gave me a chance to do all of that and more.

In the last few weeks, when I updated the program to use Nunjucks, I used Claude Code as an assistant to implement many of the changes. PureScript is notoriously niche so LLMs do not always get things right as often as they do when writing Python or TypeScript. But they do get you close enough.

I continue to like the satisfaction of writing things myself than relying on an agent (except for work where dictates of productivity and releasing a feature trump personal artisanal satisfaction), so I tend to ideate with Claude Code and then implement things by hand. Features, bugs, optimisations: I follow the same simple rule.

A few of the hobbyist programs I build get used often, fewer still give me an opportunity to tinker with for a long time. vāk happens to be one that allows for both. It's one of those home-cooked software things that I keep trying to generalise for no reason.

Bringing 1600+ Lucide icons into Elm

druchan — Wed, 04 Feb 2026 06:30:00 +0000

Lucide icons has some really wonderful icons for interface design and is one of the most popular icon sets today.

In the past, for my Elm projects, I've used Feather icons. In new Elm projects, I wanted to use Lucide Icons, only to discover that there is no Elm package to import and use Lucide icons. I was surprised: the Elm ecosystem, even if niche, pretty much supports all modern / contemporary libraries and tools. So not finding an Elm Lucide package was very surprising.

Just as surprisingly, the Feather icons Elm package hasn't been updated in 6+ years.

And so, a new side-quest was born: publishing the first elm-lucide package to bring Lucide icons to the Elm ecosystem.

The first thing I did was to find out how Feather icons were being rendered in Elm. I found this:

alignLeft : Icon
alignLeft =
    makeBuilder "align-left"
        [Svg.line [ x1 "17", y1 "10", x2 "3", y2 "10"] []
        , Svg.line [x1 "21", y1 "6", x2 "3", y2 "6"] []
        , Svg.line [x1 "21", y1 "14", x2 "3", y2 "14"] []
        , Svg.line [x1 "17", y1 "18", x2 "3", y2 "18"] []
        ]

So, just use SVG module to render the paths and other tags. The values of these tags come from the SVG content for each icon.

To do this for Lucide, I'll need two things:

download all SVG data for all the 1600+ icons on Lucide
then, for each SVG, convert the XML into Elm-syntax

Getting all the Lucide icons is simple. lucide-static is a JavaScript file that has all the SVG icons. I ran a simple curl to fetch all the icons in a single JS file.

Each icon looks like this:

const TextAlignStart = `
<svg
  class="lucide lucide-text-align-start"
  xmlns="http://www.w3.org/2000/svg"
  width="24"
  height="24"
  viewBox="0 0 24 24"
  fill="none"
  stroke="currentColor"
  stroke-width="2"
  stroke-linecap="round"
  stroke-linejoin="round"
>
  <path d="M21 5H3" />
  <path d="M15 12H3" />
  <path d="M17 19H3" />
</svg>
`;

The goal is to take the contents inside the <svg> tag, convert them into Elm-specific syntax. Basically:

from this:

<path d="M21 5H3" />
<path d="M15 12H3" />
<path d="M17 19H3" />

to this:

S.path [SA.d "M21 5H3"] []
, S.path [SA.d "M15 12H3"] []
, S.path [SA.d "M17 19H3"] []

While I pondered over this, I realized that if I could transform this SVG XML into an AST, I can then parse it to extract the relevant info I need.

For example:

{
    children: [
        { node: "path", attributes: [{ d: "M21 5H3" }] },
        { node: "path", attributes: [{ id: "M15 12H3" }] },
        ...
    ]
}

I can then use this structure and create a string which is valid Elm syntax:

S.path [SA.d "M21 5H3"] []
, S.path [SA.d "M15 12H3"] []
, S.path [SA.d "M17 19H3"] []

The trick was that I needed to do this SVG/XML to AST conversion in a Node environment. Upon research, I found that jsdom helps with this. So, I ended up doing this:

try {
  let div = new jsdom.JSDOM(
    `<div>${svgString}</div>`
  ).window.document.querySelector("div");
  let svg = div.querySelector("svg");
  icon.classList = svg.classList.toString();
  icon.children = [];
  let children = Array.from(div.querySelectorAll(`svg > *`));
  icon.children = children
    .map((c) => [c.nodeName, extractAttributes(c.attributes)])
    .map(childToList);
  return icon;
} catch (e) {
  log(e);
  return null;
}

That is:

get the SVG string (this was easy, just read the value of an exported icon from lucide-static.js)
wrap it in a <div> and make jsdom render it
then, extract what I need (svg's children)
convert each child into a tuple of [node name, node attributes as key-value pairs]

For example, for this node:

<path d="M13 21h8" />

This is the tuple I get:

["path", { d: "M13 21h8" }];

And finally, once I have all the tuples, I just convert them into Elm strings.

And I combine all of that into one large module-declaring string and then print that to an Elm file called LucideIcons.elm.

One additional trick I need to do here is to enable customization of the icon. So I construct the icon in a way where it's a function that takes an options parameter (of type List (Svg.Attribute msg)) and renders the SVG icon with those options. This allows for some nice, simple customization of the icon as an SVG element.

alignLeftIcon : List (S.Attribute msg) -> H.Html msg
alignLeftIcon options =
    S.svg (baseOptions ++ options) [S.path [ SA.d "M21 5H3"] [], S.path [SA.d "M15 12H3"] [], S.path [SA.d "M17 19H3"] [] ]

All of this is in a build.js script that automates the whole thing. When I run this, I have a LucideIcon.elm file which defines and exports all the 1600+ icons in Lucide as Elm functions.

Since the build.js script downloads the latest lucide-static, whenever there is an update in Lucide's version, I just run this and I have all the new/updated icons as well.

You can find the elm-lucide package here. I try and update as soon as there are updates to the main Lucide library.

Functional programming in an LLM world

druchan — Tue, 03 Feb 2026 06:30:00 +0000

A twenty-something and their ChatGPT has produced a code artefact that is currently in production. Somewhere deep in the code soup, there is this utility function...

function calculateShipping(weight, distance, isExpress) {
  const baseRate = 5.99;
  const weightRate = weight * 0.5;
  const distanceRate = distance * 0.1;
  const expressMultiplier = isExpress ? 2 : 1;

  return (baseRate + weightRate + distanceRate) * expressMultiplier;
}

...which then seems to get called in some other part of the codebase like so:

function processOrder(order) {
  const subTotal = order.items.reduce((sum, item) => sum + item.price, 0);
  const shipping = calculateShipping(order.weight, order.distance);
  return { total: subTotal + shipping, shipping };
}

About a week later, customers are complaining that express orders are not being charged the express rates.

The fix is easy, sure, but it's 2026. How come we're still making these errors to begin with?

In the 1970s, a lot of smart programming-language scientists and academicians wrote up a bunch of ideas about constructing, describing and writing programs in a way that was different to the then-typical von Neumann-style (i.e, imperative-style) of programming.

The idea was not just to be smart, of course. They wanted to write programs in a way that was easier to reason about , easier for mathematicians to come in and prove the correctness of the programs and, in some weird way, useful for programmers because it let them not worry about silly errors that were common in the other, imperative-style of programming.

These ideas have long since escaped the confines of academic esotericism and joined the mainstream through languages like Haskell and OCaml, and also been adopted into many languages including Rust, Swift, Java, Javascript and more.

What's the point of it all?

Well, it's baffling that we continue to produce the same class of errors that we've been producing — now, even with AI-generated code — despite the fact that hundreds of smart folks helped found ideas and mechanics of eliminating those entire classes of errors from our programs.

Things like undefined and null-pointer errors, things like missing a case in a switch/pattern-match (looking at you Typescript), things like totality, things like using generic string types where a branded-type (custom data-type) would do a much better job of catching errors early... you know, just things that make software robust, safe and error-free.

As humans we made these errors in our codebases. These trained the AI models. Now AI generates similar errors, even if not in as much quantity and frequency. AI is getting better, yes, and there are fewer instances of such errors but the very idea that such errors continue to crop up is supremely silly.

Let's take the case of static typing.

A lot of languages are dynamically typed and going strong: Python, Javascript, Clojure. But each seemingly has a superset or a library add-on that adds, to varying degrees of robustness, some kind of a type-system. Heck, an entire superset of Javascript spawned because programmers believe having types and type-guarantees is good.

But even Typescript only goes so far. And the rest, like Clojure Spec or Pydantic, go far less. On the other hand, strongly type-driven languages like Haskell, Elm and OCaml travel the farthest when it comes to guaranteeing a hell lot of safeties and bug-free programs at conception.

When AI generates dynamically-typed code, you need an elaborate set of unit tests (or property-based tests) to ensure the functions work as expected and handle cases when the input types are wrong. But when AI generates code in a strong, statically-typed language, a formidable set of static compilation checks (or a language server) ensures that the function implementation makes no mistakes with the input and output types.

Consider a function that adds money:

It's insufferably easy to get it wrong in Javascript:

const addMoney = (a, b) => a + b;
let a = 24.0; // in EUR
let b = 26.0; // in USD

addMoney(a, b); // makes no sense to add EUR and USD

Typescript introduces a way of safeguarding. It is convoluted, but it works.

type EUR = number & { readonly __brand: "EUR" };
type USD = number & { readonly __brand: "USD" };

const eur = (amount: number): EUR => amount as EUR;
const usd = (amount: number): USD => amount as USD;

const addEUR = (a: EUR, b: EUR): EUR => (a + b) as EUR;
const addUSD = (a: USD, b: USD): USD => (a + b) as USD;

let a = eur(24.0);
let b = usd(26.0);

addEUR(a, a); // ✓ works
addEUR(a, b); // ✗ Type error: USD not assignable to EUR

Here's Haskell, a pure-functional programming language:

newtype Money (currency :: Symbol) = Money Double

eur :: Money "EUR"
eur = Money 24.00

usd :: Money "USD"
usd = Money 26.00

addMoney :: Money c -> Money c -> Money c
total = addMoney eur usd -- ERROR: "EUR" ≠ "USD"

The compiler, armed with all the historic logic of strong type-checking, will prevent the code from even compiling in the first place.

With a decent LSP-LLM integration, which is now very common among the top-AI players, these kinds of bugs are caught even as the AI tries to produce code , and fed back into the AI to correct itself.

There are many ways of trying to understand programs. People often rely too much on one way, which is called “debugging” and consists of running a partly-understood program to see if it does what you expected. Another way, which ML advocates, is to install some means of understanding in the very programs themselves. - Robin Milner.

Types are not just mechanisms to create safe programs. They are useful to construct programs from scratch. Types are not just those things you use to set guardrails around how functions are called; they are the basic building blocks. These building blocks allow us to trace and understand programs far better than slapping a million debug statements and running through them tediously.

All the tooling and mechanics around this is already present. We just need to ask the AI to write programs the way functional programmers write programs: start with types, write the functions around them, and construct entire systems by putting together the pieces... by "composing".

Nowhere is this made more natural than in languages that support, inherently, the ideas of functional programming. In every other language where these ideas are an afterthought and therefore an add-on package, it is very easy for AI to escape-hatch itself and default to "just make things work" mode which can result in code that is peppered with errors.

They go by many names. Arrays, lists, vectors, slices, collections. The earliest reference to lists as a formal, mathematical concept appears at around 200 B.C. Computer science, which happens to rely so much on math, implemented arrays in the 1940s and 1950s.

In 2026, your app will crash if you have, anywhere in the code, array[1] and the array happens to be empty, or worse, a pointer to nothing.

The funny thing about this is that it doesn't matter what industrial-power language you pick: Golang, Python, Javascript (and even Typescript sometimes). Everyone will fail you. And the mistake is so prevalent across thousands of codebases that it would be almost impossible for AI not to have trained and reinforced on such ugly, disastrous patterns.

In FP, it is unidiomatic to access an index in a list. It is totally do-able, but most programmers prefer the idiomatic way, which involves a mild tedium called pattern matching.

at :: [a] -> Int -> Maybe a
at [] _ = Nothing
at (x:_) 0 = Just x
at (_:xs) n = at xs (n - 1)

-- or, better, using Vectors
at' :: Vector a -> Int -> Maybe a
at' v idx = v `!?` idx

There's a lot of things happening here, described syntactically, that create near-perfect conditions for the code to not break, crash or go crazy. The at function tries — that's an important keyword here, tries — to extract the _n_th element in a list. The three lines are pattern-matches that cover all possible cases: the list is either empty or has at least one element. If your code did not have any one of those lines, the compiler will prevent you from compiling the code. And the result of this extraction is not a guaranteed value of a. It's Maybe a, meaning, if the list was empty to begin with, you extract Nothing. Downstream, when this function is used on a list, you have to contend with the Nothing. That is, you have to tell the program what to do if the extraction resulted in Nothing.

getPrimaryEmail :: List String -> String
getPrimaryEmail emails = case at emails 0 of
    Just email -> email
    Nothing -> "noreply@nomail.com"

Why is this useful? Why is this important?

Thousands of programs have been written this way in functional languages with strong type inference. That means the data that trained the LLMs has this pattern repeat over and over again. And so, when you ask an LLM to write a Haskell or a Rust program dealing with lists, it emerges with safe code paradigms like these making your programs safer, eliminating a class of old, pesky bugs.

It is quite possible that LLMs eliminate hallucinations entirely. It is also possible (and perhaps happening) where LLM offers a pseudo-determinism in a lot of cache-able (or skill-able) actions, like when we ask it to "write a function to test for prime."

But the inherent non-determinism of output when asking it do something complex remains. That's not a bug, that's a feature."Write a program to handle a notification queue that is extensible to multiple notification channels," is a wide-ranging ask that will produce a different kind of a code every time you ask the LLM. With each iteration, there may be plenty of sneaky bugs like the ones outlined above (and more).

"But we have tests!" — yes, tests are quite possibly the finest ways of guaranteeing a program. The formal verification specialist tells me it's not true; formal verification is the surest way. But a majority of the industry doesn't spare any time or resources on formal verification of their programs. So tests are currently our only means to ensure an app works as intended despite an onslaught of vibe coded slop entering the production lines.

But imagine having to write tests to ensure somewhere in the codebase a function is not called with the wrong parameter type or an array's non-existing index is accessed. A whole class of errors are already "catch"-able at compilation; a whole class of human fallacies are already addressed thanks to the work of computational and mathematical geniuses. And not using that seems ridiculous.

Functional programming is not an easy paradigm to master. The steep learning curve (and the monads) have kept a lot of people away, and in fact driven them (back) into the arms of OOP.

But with LLMs, the slope of this curve can come down drastically. Generative AI for code and engineering reduces the need for absolute mastery in a functional language but allows us to reap the benefits of the guarantees and safety. It's not yet a perfect balance but it has the best chance of getting there.

A hell lot of code is going to get generated using LLMs this year. Till the bubble pops when AI companies increase their token prices to realistic values, organisations are going to build larger throughput pipelines directly from LLM out to production codebase. The cost is not just the tokens and the prompt engineers. The cost is all the slop and the many classes of bugs that are going to get introduced which will then need really good engineers (along with AI) to fix. And don't forget the time spent on doing that.

Part of picking the right stack is picking good, sound languages to build things with. And now might be the best time for software engineers to add FP languages to the stack to reap engineering benefits of academic rigour.

Programming rites of passage

druchan — Mon, 02 Feb 2026 06:30:00 +0000

Much to my sadistic little delight, I read this morning that vibe-coding (and other similar variations of LLM-driven software building) does not help you acquire skills or learn much.

LLMs, on the other hand, are trying to give you the sharpest, closest solution possible. When learning through an LLM (especially around bug triangulation, troubleshooting etc), there is hardly any room or potential for ancillary learning.

Although I have no data on this, I tend to believe that ancillary learning plays a crucial role in our growth as developers and engineers. This is probably true for every other line of work/study.

from an earlier writeup

Some months back, as I was refining vāk (my custom blog builder that runs my blog and is used by a grand total of 1 user), I was thinking about the fact that almost every decent programmer I know of has gone through this programmer's rite of passage that involves reinventing, for play and more, many little technologies that already have robust implementations.

The ordering may be off (I will touch upon that later) but it goes like this:

first, you build your own (portfolio) site. Instead of relying on a readymade site-builder (squarespace/wordpress back in the day), you would pick something like a framework (ew but nextjs, or astro, or some other obscure stuff) and then build your site. Hundreds of hours of theming, customising, integrating with external data-feeds (like your socials or blog) will ensue.
then, you level up by porting your journal/blog to a blog-builder of your own. You'll write this in a stack that you're either comfortable with or going gaga about at the time. Hundreds if not thousands of hours will be poured over getting the blog builder just in the right level of abstraction: enough to feel generic (but it's not), but also specific to your use-case in the right way. It's not like anyone else is going to use this but your software-engineering ethics won't let you sleep till you feel it's built like anyone can use it.
now, armed with the experience of a blog builder, you will head to writing a parser. If you're ambitious, you'll head straight for the obvious — a JSON parser. If not, you might write something that parses far less of a complicated mess. like extracting content inside SQL-code blocks inside documentation files written in markdown.
sometimes, it's possible that instead of writing a parser, you might write a library that handles strings of data, either en mass or in a stream. For the nerds, this might come in the form of implementing a protocol (think redis), or, in the case of lesser-nerds, re-inventing git.
the final boss is when you write a compiler from scratch for a language. This is meta-level at this point: writing a program to eat, grok and execute other programs. Crafting Interpreters is your new bible.

There are some more stages here that very few cross. After the compiler, you might get into PL-theory. Philosophising about "what even is language? what is grammar?" will lead you down a path where you might toy with your own language. There is no chance you won't end up doing a bit of LISPy stuff, or get into ML-like syntax before embarking on your own journey, discovering your own weird syntax.

Or you might branch out into formal verification if you're into being a stickler (and into math) for proving things right (or wrong, if you derive pleasure out of that). You'll possibly get into reading thesis papers more than layman blogposts (like these) and get into stuff that even Haskell engineers at Bellroy call "esoteric".

The inquisitive will continue to be so. The perpetually-curious who are intrinsically driven to the details and nuances will continue to be so even in the midst of this vibe-coding AI era.

I wonder what will happen to those that would like to skill up but will end up having stunted growth because vibecoding and eager-to-build LLMs are here and the humans are not conscious or aware enough to recognize that the grind (that the LLM eliminates) is what helps skill-up.

P.S: The rite of passage is not necessarily sequential. Some folks head straight to Crafting Interpreters. Some skip the blog builder and have to write parsers at their job. And some formal verification stalwarts have no skill or craving to build their own site from scratch.

LLM, the compiler.

druchan — Fri, 30 Jan 2026 06:29:49 +0000

Origin: https://notes.druchan.com/llm-as-compiler

"The new lingua franca of programming is English."

"I don't look at code anymore. I don't look at diffs."

"There is no way I can look at 3000+ diff patches anymore. It's all spec-driven."

At first, it's a hard thing to grapple with as a cautious optimist. To not look at code anymore, and yet build things that span hundreds and thousands of lines of code, seems reckless.

But what is writing JavaScript or C? The code anyway gets compiled and then "translated" into some lower-level language, eventually becoming assembly instructions. Most programmers today do not "look" at the compiled, assembly code, do we? Did the first generation of higher-level language users who almost never looked at the compiled code get frowned upon by those who wrote assembly programs by hand?

And how is this any different from today? English is the higher-level programming language, the LLM is the compiler.

The one main (and perhaps the only) difference is the non-determinism that emerges out of the fundamental way in which LLMs work (described as a stochastic parrot) vs. the deterministic outputs of compilers and transpilers. Given a piece of code in a higher language, and a compiler with a set of options, the output in assembly or bytecode will always be the same. This is a reassuring thing because this allows us to write formal "correctness" verification programs for the compilers and guarantee that the outputs will be exactly as expected and not do funny things. Doing this in the "LLM-as-compiler" model seems impossible at this time.

But, people just don't care. Businesses and organisations are in a perennial race to ship money-making features all the time and software (the way we do it) has this inherent capacity to be built fast (because there is the possibility of iterative improvements and the cost of a bug or failure is 99% of the time not catastrophic). And this "English as the programming language, LLM as the compiler" model helps in this race.

6 Aphorisms for AI-assisted Pragmatic Programming

druchan — Fri, 16 Jan 2026 06:30:00 +0000

Short aphorisms on AI-assisted (and sometimes AI-driven) software engineering.

1. AI-ludditism is futile

AI-skepticism is fair, AI-ludditism is futile.

AI-assisted programming is here to stay (unless the bubble bursts and leads to prohibitively-expensive tokens).

"AI has sucked the fun out of programming" is a proxy for AI-ludditism. The entrepreneurial programmer (who loves building things and sees writing code as a means to an end) wins while the puzzle-solver (who loves writing code) will be left behind.

2. Balance AI-driven and AI-assisted modes of operation to keep your sanity and your job

AI-assisted mode is when you alternate between driving and navigating, lots of checkpoints, have a close-to-intimate understanding of the code that is getting checked-in.

AI-driven mode is when you let the AI do almost everything, only occasionally pausing to supply a correction, a clarification or a gentle steer.

AI-assisted mode will help us retain our ability to understand, craft, update and refactor programs without atrophy. It gives us a chance to fight back against slop, and craft robust codebases. AI-driven (of which vibe coding is an extreme end) most likely leads to problems of all kinds.

Simple rule: Chores? AI-driven. Otherwise = AI-assisted.

3. Increase your surface area of impact

If AI can work at the level of a mid-engineer, what is our worth to the organization?

AI enables us engineers to increase the surface area of our impact: a frontend engineer can now build a decent first cut of a feature end-to-end, including backend and database changes; a backend engineer can now extend or add new functionality end-to-end, including frontend and doing some DevOps work.

You provide value by expanding the surface area of your impact in the team, organization, product.

4. Bad mental models = Bad instructions = Bad implementation

AI doesn't seem to be able to save you from your bad mental models.

If your internal mental model of a solution is bad to start with, your instructions to the AI reek of bad assumptions, bad directions and bad examples.

The basic tenets of software design remain intact. Simple, correct, safe software starts with simple, correct, safe mental models in the human prompter.

5. Code is still the best documentation, but AI makes grokking easy

Long spec files, implementation.md files and other such gimmicks are trying to be proxies for grokking the code but they all suffer from a plethora of issues (too long to read, outdated and obsolete within days, too many to track etc.).

Code continues to remain the best source of truth for documentation, because code is what runs and code is what lies underneath a running software.

Where AI really helps (in teams) is being able to grok the code. AI can summarize, point out the nuances, and even "reason" about many human decisions in the code.

When working with other people's code, use AI to understand.

6. Use tests, types and immutability to bring back determinism in a non-deterministic world

Generative AI produces non-deterministic outputs. This is especially scary when you let it modify existing code.

End-to-end tests, static type checking and functional ideas like immutability and managed side-effects are the antidotes and safeguards against non-deterministic code fiddling.

E2E tests guarantee the app works as expected for all users. Type checking ensures hallucinated code, hallucinated arguments do not even compile in the first place. And practices like immutability (by using a language that defaults to immutable values) eliminate a class of problems that AI-generated code can bring in (because it has been trained on a lot of human-written code that can be buggy).

Letting the compiler guarantee sortedness

druchan — Wed, 08 Oct 2025 06:30:00 +0000

It's not often that I wake up on a Sunday and the first thing my brain thinks of is a leetcode problem from two years ago. In fact, it's never. Until today.

I woke up and found myself mulling over a "gotcha" that I left unaddressed back in June 2023 when solving a fine little leetcode problem.

The tl;dr of the problem is you're given a list of stock prices for subsequent days and you have to find the maximum profit possible if you bought and sold the stock at most twice. That is, if you had a stock price list of [3, 1, 0, 0, 1, 2, 3], the best you can do is buy on the 4th day (for ₹0) and then sell it on 7th day for ₹3, you make a profit of ₹3. (There are some constraints here: you can only buy or sell on a given day; you cannot buy more unless you sell etc. Check out the writeup for more info)

SortedArray type is not all that safe

The solution I managed to cook up worked well but one of the flaws it had was something to do with sorted arrays. In the solution, I needed a sorted array of elements (elements here being some kind of pairs/tuples). In order to ensure some of the functions only allowed a sorted array (and guaranteed this at the type-level), I created a new type called SortedArray which, parameterized, looked like this:

newtype SortedArray a = SortedArray (Array a)

The problem was, I could construct a SortedArray but it could end up being completely unsorted. I just had to do this:

totallyMisleading = SortedArray ([7,6,5,7,2,0])

If I had to actually make a true-to-its-name SortedArray, I had to do this:

betterArray = SortedArray (sort [5,4,2,8,1,9,8])

It still doesn't prevent me from doing SortedArray (unsortedArray) which is a disaster waiting to happen.

Making it impossible to construct a SortedArray unless you use a function

The way to prevent this from happening is to prevent SortedArray constructor from being usable. That is easy: we put this SortedArray in a new module and only export the type.

module SortedArray (SortedArray) where
import Prelude

newtype SortedArray a = SortedArray (Array a)

Now, we add a specific function that generates a SortedArray from any array:

import Data.Array (sort)

toSorted :: forall a. Ord a => Array a -> SortedArray a
toSorted xs = SortedArray (sort xs)

You could, at this point, go: what's that Ord a thingy?

Custom data types are not really sortable... unless we tell the compiler so

The key function here is the sort which is the default "array sort". The expression sort xs works only because we tell the compiler, through the annotation, that whatever elements we're dealing with in the array are "orderable" (through that Ord a constraint in the type declaration).

So this will work out of the box:

sortedNumbers = toSorted [4,3,5,2,6]
-- sortedNumbers == [2,3,4,5,6]

But in my original solution, I was dealing with custom data types. Like these:

data StockDay = StockDay Int Int
data BuySell = BuySell StockDay StockDay

An array of elements of these kinds does not lend itself to be sorted.

sort ([StockDay 1 2, StockDay 3 4, StockDay 1 5])
-- Does not compile.

The reason is that Ord a constraint. The compiler does not know how to order an array of StockDays or BuySells because there is no Ord implementation for these data types. In English, the compiler just doesn't know how to compare two StockDays or two BuySells. If it knew that, it would know how to sort an array of StockDays or BuySells.

So, all that was left was to write some Ord instances for these two custom data types:

instance ordStockDay :: Ord StockDay where
  compare = sortStockDay

instance ordBuySell :: Ord BuySell where
  compare = sortBuySell

-- implementations of these sort functions are cut for brevity
-- sortStockDay :: StockDay -> StockDay -> Ordering
-- sortBuySell :: BuySell -> BuySell -> Ordering

derive instance eqStockDay :: Eq StockDay
derive instance eqBuySell :: Eq BuySell

(The Eq instance derivations are required in order to be able to write Ord instances for those data types.)

With these small changes, I could refactor pertinent bits of the code to get a type-level, compile-time guarantee that whatever function needed to use a SortedArray was getting a sorted array for sure.

Mucking about in other languages

Typically, these posts conclude with a sentence or two about how great this typeclass-supported polymorphism is and how you could reap the benefits mostly in languages like Haskell/Purescript (or OCaml and maybe Rust).

But in digging a little deeper into how other languages would implement a type-level guarantee of array sorted-ness even for custom data types and interfaces, I learnt that many languages support these kinds of shenanigans almost out of the box.

Mostly, it's a matter of declaring the custom "compare" functions for the custom data types and then passing it to the constructors that construct the SortedArray type.

Some allow you to "auto-derive" the sorting if the underlying types already have comparison methods defined in the standard library. For example, a Tuple/Pair. Haskell/Purescript allows us to auto-derive too but auto-derived instances for tuples and custom data types can be tricky. They can be tricky for strings too (should I compare strings lexically or by length?). The key concept here is defining what is a "comparison" is hard for some kinds of data where you have more than one dimension on which you can compare.

In these implementations, a pattern emerges. We define a custom compare function for the custom data type, then that is passed to the constructor.

Are you passing the comparator implicitly or explicitly?

When I say that's passed to the constructor, there are two ways this happens. Either it's explicit: that is, the custom compare function is passed as an argument to the constructor. Or it's implicit: the custom compare function is nowhere in the construction arguments but because a comparison method is available and associated with the datatype, the compiler (or the runtime) knows what to do, how to sort etc.

In the following examples, assume two things

we have written a constructor that would construct a SortedArray. The interface of this constructor will either need explicit passing of the compare function or not.
the code is not exactly correct. It exists more as an approximation, for illustrating how one gets things done in the langauge.

For instance, here's Typescript, an explicit beast:

type SD = { price: number; day: number };
type BuySell = { first: SD; second: SD };

// Custom comparators
const compareSD = (a: SD, b: SD) => a.price < b.price;
const compareBuySell = (a: BuySell, b: BuySell) =>
  a.second.price - a.first.price < b.second.price - b.first.price;

// Constructors; assume "SortedArray" is some class-like implementation that has a "from" method
// from: <T>(T[], compareFn: (a:T,b:T) => boolean)
const sortedSD = SortedArray.from([{ first: 3, second: 1 }], compareSD);
const sortedBuySell = SortedArray.from([buySell1, buySell2], compareBuySell);

Or Golang:

// Custom comparison functions
func compareSD(a, b SD) bool {
    // some comparison here
}

func compareBuySell(a, b BuySell) bool {
    // some comparison here
}

// Constructors
sortedSD := NewSortedArrayWith([]SD{{1,2}, {3,1}}, compareSD)
sortedBuySell := NewSortedArrayWith([]BuySell{bs1, bs2}, compareBuySell)

Contrast this with Kotlin:

data class SD(val first: Int, val second: Int) : Comparable<SD> {
    override fun compareTo(other: SD) = {} // some custom compare method here
}

data class BuySell(val first: SD, val second: SD) : Comparable<BuySell> {
    override fun compareTo(other: BuySell) = {} // some custom compare method here
}

// Constructors
val sortedSD = SortedArray.from(listOf(SD(3,1), SD(1,2)))
val sortedBuySell = SortedArray.from(listOf(BuySell(sd1, sd2), BuySell(sd3, sd4)))

Or even the more verbose, Python, we override __lt__, __eq__ and __gt__ methods:

@dataclass
class SD:
    first: int
    second: int

    def __lt__ (self, other: 'SD') -> bool:
        # some custom comparison goes here

    def __eq__ (self, other: 'SD') -> bool:
        # some custom equality check goes here

@total_ordering # Generates other comparison methods from __lt__ and __eq__
@dataclass
class BuySell:
    first: SD
    second: SD

    def __lt__ (self, other: 'BuySell') -> bool:
        # Custom: compare by sum of SD values
        self_sum = self.first.first + self.first.second + self.second.first + self.second.second
        other_sum = other.first.first + other.first.second + other.second.first + other.second.second
        return self_sum < other_sum

    def __eq__ (self, other: 'BuySell') -> bool:
        return (self.first, self.second) == (other.first, other.second)

def main() -> None:
    sd_items: List[SD] = [SD(3, 1), SD(1, 2), SD(2, 1)]
    sorted_sd: SortedArray[SD] = SortedArray.from_list(sd_items)

    buysell_items: List[BuySell] = [
        BuySell(SD(1, 2), SD(3, 4)), # sum = 10
        BuySell(SD(2, 1), SD(1, 1)), # sum = 5
        BuySell(SD(5, 5), SD(5, 5)) # sum = 20
    ]
    sorted_buysell: SortedArray[BuySell] = SortedArray.from_list(buysell_items)

The beauty of the implicit way is that we can abstract away (from our working memory) how a list/array of custom data type is sorted (or how the elements are compared). And we don't need to pass it on every time we try to generate a sorted list of things.

Kotlin solves with the Comparable<T> type which mandates that you write a compareTo function. Haskell/Purescript solve this with the Ord a constraint which requires you to provide a compare function for your custom data types (if you need sorting, comparing functionality for those data types).

The difference between explicit and implicit is kind of stark if we think about it in layman terms. When we try to construct a SortedArray, the explicit ones are going, "Okay you asked me to sort a list of things, but can you also tell me how to compare the things?" every time we try to generate a sorted array. The implicit ones are going, "Okay you asked me to sort a list of comparable things and somewhere in the codebase you've mentioned how to compare this specific thing so I will now construct the sorted array for you."

There is one pitfall though.

What does it even mean to "compare" two things?

It is mostly straightforward if we think of numbers. Comparison is greater-than or less-than or equal-to. Booleans can be compared too if we assume True > False.

But what about strings? Should we compare them just lexically or should we also include the length in the comparison? Or what if, for a specific use-case, we only want to compare the length?

As an example, how to compare "apple" and "pear" depends on the context. Lexically, "apple" comes first. By length, "pear" comes first. Typically, we would do lexical followed by length — a useful but arbitrary convention.

Things get complex when we talk about product types. Product types are your objects or structs or dataclasses with multiple fields. These have multiple "dimensions" and what that means is there are many ways of comparing them. And each way could be valid and multiple comparing methods could be necessary.

Take my StockDay.

data StockDay = StockDay Price Day
type Price = Int
type Day = Int

This is basically a Tuple, but represented as data for type-level convenience.

What does comparing or sorting two StockDays mean? In my limited use-case, it just means comparing on Price. But there could be a use-case where I want to sort them by Day.

The Ord instance will completely fail me in this case.

A naive, incomplete, pair-product-only solution would be:

class Sortable a where
  compareFst :: a -> a -> Ordering
  compareSnd :: a -> a -> Ordering
  compareBoth :: a -> a -> Ordering

instance sortableStockDay :: Sortable StockDay where
  compareFst (StockDay p1 _) (StockDay p2 _) =
    if p1 < p2 then LT else GT
  compareSnd (StockDay _ d1) (StockDay _ d2) =
    if d1 < d2 then LT else GT
  compareBoth s1 s2 =
    case compareFst s1 s2 of
      EQ -> compareSnd s1 s2
      ord -> ord

But there is no way for me to let the compiler or the runtime know dynamically which comparing function to use when I sort an array:

toSorted :: Array a -> SortedArray a
toSorted xs = SortedArray (Array.sort xs)
-- but notice how I cant tell the sort algo which sort to use

I would have to write a different function for each type of sort:

toSortedFst :: forall a. Sortable a => Array a -> SortedArray a
toSortedFst xs = SortedArray (Array.sortBy compareFst xs)

toSortedSnd :: forall a. Sortable a => Array a -> SortedArray a
toSortedSnd xs = SortedArray (Array.sortBy compareSnd xs)

And now notice how it's lost some guarantees again because I could end up using the toSortedFst where I should be using toSortedSnd and there would be nothing preventing me from doing that. The types would check.

Languages like OCaml and Rust have context-specific comparisons. So you could essentially have multiple ways to compare and when you try to sort, you can pass it an additional information that tells the compiler/runtime which comparison to use.

(* Define the interface *)
module type COMPARABLE = sig
  type t
  val compare : t -> t -> int
end

(* Different comparison strategies *)
module StringLexical : COMPARABLE with type t = string = struct
  type t = string
  let compare = String.compare
end

module StringByLength : COMPARABLE with type t = string = struct
  type t = string
  let compare s1 s2 = compare (String.length s1) (String.length s2)
end

module StringByLengthThenLexical : COMPARABLE with type t = string = struct
  type t = string
  let compare s1 s2 =
    let len_cmp = compare (String.length s1) (String.length s2) in
    if len_cmp = 0 then String.compare s1 s2 else len_cmp
end

(* Generic sort function *)
let sort (module Cmp : COMPARABLE) list =
  List.sort Cmp.compare list

(* Usage - explicit choice of comparison *)
let words = ["hello"; "hi"; "world"; "a"; "programming"]

let () =
  (* Sort lexicographically *)
  let lexical = sort (module StringLexical) words in
Printf.printf "Lexical: %s\n" (String.concat "; " lexical);
  (* Output: Lexical: a; hello; hi; programming; world *)

  (* Sort by length *)
  let by_length = sort (module StringByLength) words in
  Printf.printf "By length: %s\n" (String.concat "; " by_length);
  (* Output: By length: a; hi; hello; world; programming *)

  (* Sort by length then lexical *)
  let combined = sort (module StringByLengthThenLexical) words in
  Printf.printf "Length then lexical: %s\n" (String.concat "; " combined)
  (* Output: Length then lexical: a; hi; hello; world; programming *)

(* You can even parameterize functions by comparison strategy *)
let find_max (module Cmp : COMPARABLE) list =
  match list with
  | [] -> None
  | hd :: tl -> Some (List.fold_left (fun acc x ->
      if Cmp.compare x acc > 0 then x else acc) hd tl)

let () =
  let words = ["cat"; "elephant"; "a"; "dog"] in

  (* Max by lexical order *)
  (match find_max (module StringLexical) words with
   | Some max -> Printf.printf "Lexical max: %s\n" max (* elephant *)
   | None -> ());

  (* Max by length *)
  (match find_max (module StringByLength) words with
   | Some max -> Printf.printf "Length max: %s\n" max (* elephant *)
   | None -> ())

We're using the same "sort" keyword but we get to instruct the language to use a different algorithm using that (module ....) declaration. That is rad.

Arguably, these are edge-cases. It's not often that one needs multiple strategies to compare two things which then affects how one sorts their list. But the fact that language designers in Rust and OCaml thought of these cases as well — and generalised them enough — is quite fascinating.

But it's just a wrapper! I shouldn't have to rewrite all methods

The SortedArray is merely a wrapper around Array. But because of the wrapping, any time I want to use an Array-like function (eg head, or tail or !! which is an operator to access the element at an index), I have to re-implement it. Like this:

head :: forall a. Ord a => SortedArray a -> Maybe a
head (SortedArray xs) = Array.head xs

filter :: forall a. Ord a => (a -> Boolean) -> SortedArray a -> SortedArray a
filter pred (SortedArray xs) = SortedArray (Array.filter pred xs)

-- and so on

You'd think that with all the advancements in compilers and type systems and type theory, this overhead wouldn't be required. After all, SortedArray is just a wrapper around a simple Array.

Of course, languages like Haskell/Purescript lets you kind of get rid of this overhead.

To do this, we just do some "derive"s:

derive instance newtypeSortedArray :: Newtype (SortedArray a) _
derive newtype instance functorSortedArray :: Functor SortedArray
derive newtype instance foldableSortedArray :: Foldable SortedArray
derive newtype instance traversableSortedArray :: Traversable SortedArray
derive newtype instance applySortedArray :: Apply SortedArray
derive newtype instance applicativeSortedArray :: Applicative SortedArray
derive newtype instance bindSortedArray :: Bind SortedArray
derive newtype instance monadSortedArray :: Monad SortedArray

This gives us the ability to run operations like map and fold but for other array operations like length, we have to write our functions. Instead of doing unwrap/wrap over and over again, the newtype derivation allows us to simply use a generic function called coerce which does the unwrapping and wrapping for us:

import Data.NewType (coerce)

length :: SortedArray a -> Int
length = coerce Array.length

All this is great but there are downsides and flaws to this approach.

When we derive newtype instance for a type like SortedArray, the compiler makes the SortedArray constructor "exposed". That goes all the way back to my original problem with my old solution — exposing the constructor means I could construct a non-sorted-array and wrap it in SortedArray to make it look like it is sorted. But it won't be.

The other issue, specific to this use-case, is that deriving functions like map automatically does not keep the sorted-ness guarantee.

This is wrong (and depending on the usage, dangerous):

map :: (a -> b) -> SortedArray a -> SortedArray b
map = coerce Array.map

wrong = map (\x -> x * -1) (SortedArray [1,2,3,4])
-- wrong == SortedArray [-1,-2,-3,-4]

alsoWrong = map (\x -> if x > 4 then x * -1 else x) (SortedArray [1,2,3,6,7])
-- alsoWrong == SortedArray [1,2,3,-6,-7]

And there's nothing that informs me of that unless I peak into the mapping function.

The correct map goes like this:

map : forall a b. Ord a => Ord b => (a -> b) -> SortedArray a -> SortedArray b
map f xs = toSorted (Array.map f (fromSorted xs))
-- or more succinctly
-- map f = toSorted <<< Array.map f <<< fromSorted

There are a handful of other functions that would break sorting if coerce-d through newtype derivations. Like mapWithIndex / indexedMap, insert, update, cons/snoc/push etc. Anything that updates elements (in-place or as a new result) while retaining the array-like structure is a problem.

I started this writeup as a journal entry after toying around with SortedArray's compiler guarantees. But as I wrote, I began exploring around and ended up in various rabbit holes of parameterisation, polymorphism and typeclass-like behaviours of other languages.

Some wonderful abstractions here if you are mindful of the gotchas.

AI Productivity Kool-Aid

druchan — Fri, 08 Aug 2025 06:30:00 +0000

A polarised world is usually a disaster but the entertainment-quotient is enormous. And so, as much as I dislike the kind of polarisation that's happening in my small little world of software developers about AI and LLM-driven software engineering, I tell you, it is incessantly entertaining.

On the one hand, the clickbait headlines and the trying-too-hard-not-to-sound-like-a-promotion-for-my-business opening salvos on LinkedIn posts have made all pronouncements there are to be made about the game-changing nature of AI-driven engineering and product-building. On the other, small little indie blogs are silently declaring war on the same thing, citing dead-end goose-chases and wasted productivity from the very same AIs.

What is actually happening? This is left to academics who have enough time to study. The engineers — both the ones vibing their way into a feature or out of a bug, and the rest who just canceled their Cursor subscription and went back to neovim — simply don't have the bandwidth.

The verdict from the academics (to the simple-sounding question "Does AI make the software dev more productive?") seems laced with the most common phrase you hear in software circles: it depends. (Well, they reported a 19% decrease in a narrow group).

The landscape is quite divided and there are no clear answers yet. Vibe coders are producing software artefacts in the time it would've taken a senior developer to setup the frontend. But elsewhere, the state-of-the-art model has already misdirected someone in a 2-hour hair-pulling bug hunt. The joke is that the bug was written by Claude in the first place during that vibe coding session.

A single vibe-coded artefact brings surprise and shock at the same time — founders and top-level collars are surprised at the result because they go, "imagine the possibilities now!", and software engineers are shocked at the codebase because, "who the f— writes code like this?" (plus, "oh god, now I have to clean this mess up within unreasonable timelines).

Amidst the haze, I think some clarity has been achieved collectively. We now understand that this AI-driven productivity gains is quite possible in some scenarios; notably, building prototypes from scratch and grunt-work that's easy to verify. Elsewhere, disaster rules.

Founders and top-level managers who seldom code but have hundreds of ideas they'd like to build and profit from have the ultimate tool — building prototypes of what they have been dreaming about is easier than ever before and involves very little money, very little time and, often, very little coaxing of the LLMs.

Grunt-work that you would otherwise debate between writing an automation for or just doing manually — and end up spending way too much time trying to write that automation script, immortalised by Randall — is now a couple of prompts away (usually).

Between these poles of birthing a prototype through vibe-coding and letting an LLM loose on mindless grunt-work, there is a large swath of land. A land of complex, large codebases needing a feature add. Of imperfect code with duplications and edge-case bugs and occasional reflection of human fallacies requiring large-scale refactors. Of codebases in obscure languages or frameworks asking for bug fixes. The folks at the poles have tasted immense success and productivity through AI and what they expect is that the folks dealing with this large, unruly land tame the wilderness with AI. It is a reasonable expectation in a perfect world where patterns are unblemished and consistent. Alas, LLMs are anything but.

But beyond all this, there's something that bothers me.

What to do with the productivity gains? Are you going to empower people to spend less time on work and more time on their personal lives or are you going to make them march to death to the tunes of profit-maximisation and shareholder happiness?

If we go by the historic behaviour of the industrialised world, there's only sad news. Technological progress has brought more work-hours and less work-life balance — exactly the opposite of things technological progress was supposed to offer — to the lives of the workers. This new kid on the tech-progress block is no different.

Embracing ReaderT finally

druchan — Fri, 18 Apr 2025 19:21:07 +0000

Intended audience: programmers, esp those with functional-programming background.

My last outing with the ReaderT monad was a minor disaster and I ended up writing a custom wrapper that got the job done. At the time, the monad-stacking behavior was new to me and I couldn't make sense of the code I was getting into.

Recently, I added a global-config in my blog-generator project (vāk). A handful of things needed to be dynamic and set from the shell env, and these get set into the global config which then gets passed around the app in multiple places.

I thought it was time for another outing with the ReaderT monad.

vāk's codebase is simple, in the sense that almost all effectful functions are just Aff a, which get rolled into top-level ExceptT functions and the main function "runs" these top-level functions. At a high-level, this just meant that I had to retain the same behavior but only change the top-level function to be ReaderT wrapping around an ExceptT and the main function just runs runReaderT and runExceptT (which I can compose into a runAppM).

But of course, a lot of Aff a functions were internally calling a getConfig function (which is the global config getter). So, the idea was make those functions which called getConfig use the ReaderT monad transformer's ask function and that means those functions became ReaderT instead of Aff.

And thus began the conversion of all such functions.

Some functions still remained Aff because either global config was passed to them as a parameter, or they did not use the global config at all.

Composing an Aff and a ReaderT meant that I had to "lift" the Aff into ReaderT. The liftAff instance does not work though because it does not "handle" errors. So, I ended up rolling my own:

liftAppM :: forall a. Aff a -> AppM a
liftAppM aff = ReaderT \_ -> ExceptT $ try $ aff

Now, the Aff is run, errors are "caught" via try, converted into an Either and then all of that is rolled into an ExceptT, wrapped around a ReaderT leading to my AppM:

type AppM a = ReaderT Config (ExceptT Error Aff) a

I liked how I was able to, with this liftAppM, gradually move functions around until everything was neatly converted.

For instance, if this was the pre-ReaderT function:

buildSite :: Config -> ExceptT Error Aff Unit
buildSite config = ExceptT $ try $ do
    initializeStuff config
    posts <- processBlogPosts
    -- and about 15 more lines of function calls, each in the 'Aff' monad

I could do this:

buildSite :: AppM Unit
buildSite = do
    config <- ask
    liftAppM $ do
      initializeStuff config
      posts <- processBlogPosts
      -- rest

Then, I'll see that processBlogPosts calls for config internally, so I'd have to make it use ask and therefore, turn it into an AppM. This means I'd also move function above it (initializeStuff) into an AppM:

buildSite :: AppM Unit
buildSite = do
    config <- ask
    initializeStuff
    posts <- processBlogPosts
    liftAppM $ do
        -- rest of the stuff

This way, I could gradually move things out of the inner liftAppM and finally get rid of it altogether. Just the logging bits remained in a generic m monad and could be lifted into my AppM via liftAppM so:

buildSite :: AppM Unit
buildSite = do
  config <- ask
  liftAppM $ Logs.logInfo "Starting..."
  liftAppM $ createFolderIfNotPresent tmpFolder
  postsMetadata <- generatePostsHTML
  liftAppM $ Logs.logSuccess $ "Posts page generated."
  liftAppM $ Logs.logInfo $ "Generating archive page..."
  _ <- writeArchiveByYearPage postsMetadata
  liftAppM $ Logs.logSuccess $ "Archive page generated."
  liftAppM $ Logs.logInfo $ "Generating home page..."
  _ <- createHomePage postsMetadata
  liftAppM $ Logs.logSuccess $ "Home page generated."
  liftAppM $ Logs.logInfo $ "Copying 404.html..."
  _ <- liftEffect $ execSync ("cp " <> config.templateFolder <> "/404.html " <> tmpFolder) defaultExecSyncOptions
  liftAppM $ Logs.logSuccess $ "404.html copied."
  liftAppM $ Logs.logInfo "Copying images folder..."
  _ <- liftEffect $ execSync ("cp -r " <> "./images " <> tmpFolder) defaultExecSyncOptions
  liftAppM $ Logs.logSuccess $ "images folder copied."
  liftAppM $ Logs.logInfo "Copying js folder..."
  _ <- liftAppM $ liftEffect $ execSync ("cp -r " <> "./js " <> tmpFolder) defaultExecSyncOptions
  liftAppM $ Logs.logSuccess "js folder copied."
  liftAppM $ Logs.logInfo "Generating styles.css..."
  _ <- generateStyles
  liftAppM $ Logs.logSuccess "styles.css generated."
  liftAppM $ Logs.logInfo "Generating RSS feed..."
  _ <- Rss.generateRSSFeed (take 10 postsMetadata)
  liftAppM $ Logs.logSuccess "RSS feed generated."
  liftAppM $ Logs.logInfo $ "Copying " <> tmpFolder <> " to " <> config.outputFolder
  _ <- liftAppM $ createFolderIfNotPresent config.outputFolder
  _ <- liftAppM $ liftEffect $ execSync ("cp -r " <> tmpFolder <> "/* " <> config.outputFolder) defaultExecSyncOptions
  liftAppM $ Logs.logSuccess "Copied."
  liftAppM $ Logs.logInfo "Updating cache..."
  _ <- Cache.writeCacheData
  liftAppM $ Logs.logSuccess "Cached updated."

There are (monad-reader-transformer) lift instances for both Aff and ExceptT but both will fail to handle errors.

Here's the implementation for ExceptT that will get called:

instance monadTransExceptT :: MonadTrans (ExceptT e) where
  lift m = ExceptT do
    a <- m
    pure $ Right a

If the m action throws an error, the app just crashes. Typically, I'd like for it to be returned as a Left value (the way non-errors are getting returned as Right).

I am still not very clear about the mechanics here though; tests with native monad-reader-transformer instances of lift for both Aff and ExceptT seem to crash the app instead of allowing the user to handle them in a custom way:

test :: Effect Unit
test = launchAff_ $ do
  config <- getConfig
  res <- runAppM config $ do
    lift $ ExceptT $ do
      testAff
  liftEffect $ logShow res

testAff :: Aff (Either Error Unit)
testAff = do
  throwError $ error "test error"

Running test will crash the app.

Hence, the custom (and poorly-named) liftAppM.

A Minimal Static Blog Generator in Purescript - My Notes and Code Walkthrough

druchan — Sun, 13 Apr 2025 12:54:01 +0000

Intended audience: basic functional programming know-how, Haskell/Purescript newbies/enthusiasts.

About two years ago, I decided to move my Tumblr blog to some sort of a custom-made static blog generating tool written in Purescript (a Haskell-inspired language that compiles to JS).

I've wanted to chronicle the work on this codebase at various times but never got around to doing it. Somehow, I convinced myself that the write-up would be boring to readers and not of ~~much~~ any value.

Nevertheless, I decided that I'll at least jot down some notes from the codebase and maybe someone finds it interesting enough.

GitHub source of the project

Why another static blog/site generator? And why Purescript?

Coming out of Tumblr, I vaguely remember looking at some static site options. Many of them were feature behemoths (Next.js). Smaller, fancy ones like 11ty caught my eye but it still felt ceremonious to get started with them.

On the other hand, I was itching to do something in Purescript (I've learnt stuff better by building things).

So it was just a matter of wanting to learn a language and also to end up creating a nice little, ultra-minimal static blog generating setup for myself.

Too often, people end up in the "do not reinvent the wheel" mentality. This is great mantra for a business/startup. But if you want to learn things, you have to constantly reinvent stuff.

What's in a static blog generator?

At the very core of static site/blog generators, it is all about generating HTML pages. You run a script and it collects all the data it needs and then writes HTML pages to your disk. You then host these HTML pages as your site/blog.

When I started this project, this was my basic, high-level mental model:

I will write posts in markdown files that are saved inside a contents folder
When I run the script, it will read the contents of each markdown file, convert that into HTML, then use a "template" where it will replace the body with the HTML and save the final result as an HTML file.
I will also generate, through the script, an index.html that will render all posts in reverse chronological order. You know, like a blog.

The build steps are basically:

get a list of markdown files from a folder (these are the blog posts to generate HTML files for)
for each file: read the contents, convert markdown into HTML, replace the body from a template string with this HTML, write the final thing to an HTML file.
finally, generate an index HTML file (from a template), replacing the body with a list of all posts, linking each post to its HTML file.

Eventually, I ended up adding more bits like an RSS feed, an archive page, a more customized index page etc.

Building from the smallest unit of work

You can either solve things top-down (write the main function first, then fill out the constituent functions) or bottom-up (write functions for the smallest unit of work and then compose upwards).

In this one, I went bottom-up for the most part.

The smallest unit of work was something like this:

read a markdown file
convert the contents into HTML
replace a template string with that HTML
write the updated template string to a file with the same slug/name as the markdown file.

The trickiest part was converting markdown to HTML. There is a library in Purescript that does this but I can't remember why I did not use it and instead, used something called an FFI to tap into JS code.

I have a JS module that exports a helper function (which takes a markdown string, and converts that into an HTML string, and returns an object of that data).

// Utils.js
const md2FormattedDataService = new MarkdownIt({ html: true });
const md2RawFormattedData = (string) => {
  const r = matter(string);
  return {
    frontMatter: {
      ...r.data,
      date: formatDate("YYYY-MM-DD")(r.data.date),
      tags: r.data.tags?.split(",") ?? [],
      status: r.data.status || "published"
    },
    content: md2FormattedDataService.render(r.content),
    raw: string
  };
};

This is then imported into my Purescript module (the filename is same as that of the JS file. Utils) as a foreign-function.

-- Utils.purs
foreign import md2RawFormattedData :: String -> RawFormattedMarkdownData

type RawFormattedMarkdownData =
  { frontMatter ::
      { title :: String
      , date :: String
      , slug :: String
      , tags :: Array String
      , status :: String
      }
  , content :: String
  , raw :: String
  }

Now, I can compose a function that does the unit of work:

writeHTMLFile :: Template -> FormattedMarkdownData -> Aff Unit
writeHTMLFile template pd@{ frontMatter } = do
  config <- askConfig
  res <- try $ writeTextFile UTF8 (tmpFolder <> "/" <> frontMatter.slug <> ".html") (replaceContentInTemplate template pd)
  _ <- case res of
    Left err -> log $ Logs.logError $ "Could not write " <> frontMatter.slug <> ".md to html (" <> show err <> ")"
    Right _ -> log $ Logs.logSuccess $ "Wrote: " <> config.contentFolder <> "/" <> frontMatter.slug <> ".md -> " <> tmpFolder <> "/" <> frontMatter.slug <> ".html"
  pure unit

replaceContentInTemplate :: Template -> FormattedMarkdownData -> String
replaceContentInTemplate (Template template) pd =
  replaceAll (Pattern "{{title}}") (Replacement $ "<a href=\"./" <> pd.frontMatter.slug <> "\">" <> pd.frontMatter.title <> "</a>") template
    # replaceAll (Pattern "{{content}}") (Replacement pd.content)
    # replaceAll (Pattern "{{date}}") (Replacement $ formatDate "MMM DD, YYYY" pd.frontMatter.date)
    # replaceAll (Pattern "{{page_title}}") (Replacement pd.frontMatter.title)

The replaceContentInTemplate function is a pure, side-effect-less function which replaces marked slots (like {{content}}) in a string template with the right data, producing a final HTML string.

In the writeHTMLFile function, I just try and write the file with the contents thus produced.

What's worth noting is that the function is designed never to fail. It always returns unit (via pure unit) because if things go wrong, they should not crash the building. (That is to say, if one post does not get converted into an HTML file for whatever reason, it should not prevent others from getting converted).

To do this, I use a try which takes a function that could throw, and converts it into an Either value — that is, if the function throws, you will get a Left value. If not, a Right value.

A part that's missing in the code snippet is the md2rawFormattedData function:

readFileToData :: String -> Aff FormattedMarkdownData
readFileToData filePath = do
  contents <- readTextFile UTF8 filePath
  let
    fd = md2FormattedData contents

    fdraw = md2RawFormattedData contents
  if fd.frontMatter.status == InvalidStatus then
    throwError $ error $ "Invalid status in " <> filePath <> "." <> "Found -> status: " <> fdraw.frontMatter.status
  else
    pure fd

As it turns out, the script (at the time of writing this) reads all markdown files and converts them in a different step and then passes that list of converted data through the script.

Parallel processing in Purescript

There are a bunch of options in Purescript to do parallel computation. I faced this need quite early.

The whole deal is about processing a bunch of files. That is, running them through the same functions.

So once I had a set of functions that could process one file, I could simply traverse through them. Traverse is functional-programming-speak for looping through data (typically, list-like/array) and performing some action every time on the data while also accumulating the results. Think of JS's map but imagine each item is not just transformed but you do some side-effectful action as well.

For example:

filePathsToProcessedData :: Config -> Array String -> Aff (Array FormattedMarkdownData)
filePathsToProcessedData config fpaths = parTraverse (\f -> readFileToData $ config.contentFolder <> "/" <> f) fpaths

Here, I am trying to work through an array of file paths (Array String). Each file path is passed to the readFileToData (which converts a markdown file to its HTML equivalent, see above). And I can do this in parallel trivially by using the parTraverse function.

In parTraverse the result of each computation is retained and returned in the same data structure that was passed. So, passing an array would result in returning an array of values corresponding to each application/computation of readFileToData. That's why you see this:

readFileToData :: String -> Aff FormattedMarkdownData
filePathsToProcessedData :: Config -> Array String -> Aff (Array FormattedMarkdownData)

That is, the filePathsToProcessedData function, which uses parTraverse returns an array (inside an Aff context, which denotes some side-effectful action) of FormattedMarkdownData.

There is also a variant of parTraverse where you don't care about the results. It's called parTraverse_. I use that when generating HTML files from the set of converted posts:

generatePostsHTML :: Array FormattedMarkdownData -> Aff Unit
generatePostsHTML fds = do
  template <- readPostTemplate
  _ <- parTraverse_ (\f -> writeHTMLFile (Template template) f) fds
  pure unit

Side-effects, Aff monad, errors and the ExceptT transformer

Side effects in languages like Haskell and Purescript are usually of the type IO or Eff/Aff (Aff is asynchronous, whereas Eff is synchronous).

It took me a while to get used to these. To be clear, it's easy to write a function that uses one of these. What is harder is to then "compose" them in other functions and also to handle errors correctly. With a better understanding of the monadic composition and experience with some transformers (i.e one level higher abstraction over monads), things became a little easier.

The blog generator is peppered with Aff everywhere because there's reading from files and writing to files going on and all of these are side-effects from a functional programming standpoint.

Affs (and IOs and Effs) can throw errors. Unfortunately, this is not explicit in the type information. You just assume that these computations can fail and throw an error, causing your app/script to crash.

One way to handle this is to wrap the computation in a try function; this will change a result from Aff a (where a is any type, called polymorphic type) to Aff (Either e a) (where e = any error type). By converting it to Either, you capture the error as a value.

The downside to this is that composition becomes difficult.

That is, before using try:

doAction1 :: Aff a
doAction2 :: a -> Aff b

-- can be composed easily:
doCombined = do
  a <- doAction1
  doAction2 a

But with try, in an attempt to catch errors:

doAction1 :: Aff (Either e a)
doAction2 :: a -> Aff (Either e b)

doCombined = do
  res <- doAction1
  case res of
    Left e -> pure (Left e)
    Right a -> doAction2 a

That is, I have to pattern match and extract. This gets harder and complex when more functions are involved in the computation/combination.

To circumvent this issue, we can use something called monad transformers. Specifically for our case, ExceptT. (all monad transformers are idiomatically typed with an ending capital T — ExceptT, EitherT, ReaderT, etc.)

I can now rewrite this as:

doAction1 :: ExceptT e Aff a
doAction2 :: a -> ExceptT e Aff b

doCombined :: ExceptT e Aff b
doCombined = do
    a <- doAction1
    doAction2 a

-- and then to actually run the computation:
doCombinedRun :: Aff (Either e b)
doCombinedRun = runExceptT doCombined

ExceptT allows me to retain the simple, straight-forward coding style without using try and pattern matching the Either value, but it bakes error-handling in for free.

Things of type ExceptT are really actions to be done. That is, they have to be run. To do this, we have runExceptT which is of this type:

runExceptT :: ExceptT e m a -> m (Either e a)

-- or more concretely in my case
runExceptT :: ExceptT e Aff a -> Aff (Either e a)

It takes an ExceptT and "runs" it, and if it threw an error, you get an Aff (Left e) and if it ran the computation successfully, it returns an Aff (Right a).

Armed with this information, and excited that now I can simplify the app, I converted a lot of functions to be ExceptTs. But this posed a new problem: I had to unwrap actions (ie, run them) a few times at different places. That re-introduced the pattern matching code.

Eventually, I figured a way to not do that and instead, just have a top-level ExceptT instead.

So, the app's core functions — eg, building the site (buildSite) — are of the ExceptT type but all the functions that go into composing the buildSite and other core functions are just Affs. They can throw errors, sure, but they'll all be caught in the top-level, core functions.

As an example:

buildSite :: Config -> ExceptT Error Aff Unit
buildSite config = ExceptT $ try $ do
    -- a lot of `Aff a` functions go here

And in the main:

launchAff_
    $ do
        config <- askConfig
        res <- runExceptT $ buildSite config
        case res of
        Left err -> log $ Logs.logError $ "Error when building the site: " <> show err
        Right _ -> log $ Logs.logSuccess "Site built and available in the " <> config.outputFolder <> " folder."

Where a function throwing an error should not be bubbled up, I do an in-place try and catch the errors early:

writeHTMLFile :: Template -> FormattedMarkdownData -> Aff Unit
writeHTMLFile template pd@{ frontMatter } = do
  config <- askConfig
  res <- try $ writeTextFile UTF8 (tmpFolder <> "/" <> frontMatter.slug <> ".html") (replaceContentInTemplate template pd)
  _ <- case res of
    Left err -> log $ Logs.logError $ "Could not write " <> frontMatter.slug <> ".md to html (" <> show err <> ")"
    Right _ -> log $ Logs.logSuccess $ "Wrote: " <> config.contentFolder <> "/" <> frontMatter.slug <> ".md -> " <> tmpFolder <> "/" <> frontMatter.slug <> ".html"
  pure unit

Passing global config around

In recent times, I've been trying to make my blog generator as much configurable as possible. The templates folder, the contents folder etc. that had been historically hard-coded are now customizable through environment variables (shell env).

This meant that all the functions that used these hard-coded values would now need to depend on a global config. So, I'd either have to pass the config as another function parameter/argument, or make these functions read from the global config somehow.

There are two approaches possible:

initialize the global config at the start of the app (typically, the main function) and then pass the config object down the wire to all functions. This would lead to what React devs call prop-drilling.
or, use the ReaderT monad transformer pattern where functions can "ask" for the config object and then use it, but the moment functions do this, they become side-effectful functions (if they already weren't).

I decided that for my script, I did not have to go all the way to a ReaderT, and I could just get away with a simple askConfig function like this:

askConfig :: Aff Config
askConfig = liftEffect $ do
  templateFolder <- lookupEnv "TEMPLATE_DIR" >>= (pure <$> fromMaybe defaultTemplateFolder)
  outputFolder <- lookupEnv "OUTPUT_DIR" >>= (pure <$> fromMaybe defaultOutputFolder)
  contentFolder <- lookupEnv "POSTS_DIR" >>= (pure <$> fromMaybe defaultContentFolder)
  totalRecentPosts <- lookupEnv "RECENT_POSTS" >>= (pure <$> fn)
  pure $ { templateFolder: templateFolder, outputFolder: outputFolder, contentFolder: contentFolder, newPostTemplate: defaultBlogpostTemplate templateFolder, totalRecentPosts: totalRecentPosts }
  where
  fn :: Maybe String -> Int
  fn x = fromMaybe defaultTotalRecentPosts $ (x >>= fromString)

For functions that already are Aff a, I can get the config without disturbing the function's type. For those that are "pure", I just pass the config as the first argument.

This refactor was simple but I also remember feeling happy for the guarantees of the Purescript compiler in making sure I was refactoring things without breaking them in the process.

Adding a simple cache mechanism to optimize build times

A full (cache-less) build of the site with ~140 posts takes ~3 seconds so there is really no need for a caching mechanism but it's one of those niceties to have, so I added that in.

Figuring out a simple cache logic was interesting. The goal was to know what files got modified and what didn't and using system commands (stat) made it quite easy.

Each file can then be mapped to its modification datetime and stored as some kind of key-value thing in a file:

a-breeze-of-wisdom::Feb 28 14:18:11 2025 Feb 28 14:18:11 2025
a-naive-thought::Mar  1 11:54:00 2025 Mar  1 11:54:00 2025
a-vengeful-society-vs-a-corrective-society::Feb 28 14:18:11 2025 Feb 28 14:18:11 2025
aaji::Feb 28 14:18:11 2025 Feb 28 14:18:11 2025

At the time of building the site, I just read from this file, check the last modified datetime value of the file and compare it with current, and decide if the file needs a re-build.

The getStat function helps get the stat data which is then used for the cache generation. A parTraverse helps compose getStat over a list/array of files:

getStat :: FilePath -> String -> Aff ({ slug :: String, stat :: String })
getStat contentsFolder slug = do
  buf <- try $ liftEffect $ execSync ("stat -f \"%Sm %Sc\" -n " <> contentsFolder <> "/" <> slug <> ".md") defaultExecSyncOptions
  case buf of
    Left _ -> pure $ { slug, stat: "" }
    Right buffer -> do
      b <- try $ liftEffect $ toString UTF8 buffer
      case b of
        Right s -> pure { slug, stat: s }
        Left _ -> pure { slug, stat: "" }

getStatAll :: Array String -> Aff (Array { slug :: String, stat :: String })
getStatAll slugs = do
  config <- askConfig
  parTraverse (getStat config.contentFolder) slugs

More commands!

For a long time, invoking the blog generator script would immediately start building the blog. But CLI tools usually have dedicated commands that print help, version etc.

So I modified the code to do some of those things.

Going for an arg-parsing library for this (in Haskell, something like optparse-applicative, in Purescript, something like the yargs library?) seemed overkill so I went with a simple pattern match that took the args, and then converted it into a Command type:

data Command
  = Build
  | ShowVersion
  | Help
  | NewPost String
  | Invalid

mkCommand :: Array String -> Command
mkCommand xs = case head (drop 2 xs) of
  Just "version" -> ShowVersion
  Just "help" -> Help
  Just "build" -> Build
  Just "new" -> case head $ drop 3 xs of
    Just slug -> NewPost slug
    _ -> Invalid
  _ -> Invalid

main = do
  args <- argv
  cmd <- pure $ mkCommand args
  case cmd of
    Help -> log $ helpText
    -- ...rest of the code

The "NewPost" was a recent addition: it allowed me to create a new blogpost using a template so that I didn't have to type out all the metadata.

The complexities of using TailwindCSS

The project uses/supports use of Tailwind CSS classes and directives so I could pepper my templates and stylesheets and even markdown with Tailwind's CSS classes.

The tricky bit comes where I have to use Tailwind generate the final, compiled CSS file.

I generate the site in a dedicated temporary folder — so all rendered HTML files are put there, along with copied JS/CSS/image files in respective folders. Then, I run Tailwind to compile the final CSS output. And once all that is done, I just copy over everything into a public folder which can then be used to host/serve.

Here, I have two options: use Tailwind CLI to compile it, or use Tailwind via NPM to do the same.

Using Tailwind via NPM means installing tailwindcss and then invoking npx @tailwind/cli. This creates a node_modules folder, a package.json and a package-lock.json which I have to then cleanup. An older version of the generator did precisely all this.

In the new version, the script assumes that you have the Tailwind CLI standalone installed on your machine, and is invokable as a simple tailwindcss command.

Eventually, I'd like to improve logging and customization around this. For example, if you do not rely on Tailwind classes and roll your own, you should be able to set a flag or something to disable my script from running the Tailwind command.

Simple, colorful logging

On another project for testing Steampipe queries, I use a simple pattern for logging with colors for success, error and warning/info. I decided to use that in this project too.

The logging looks like this:

And this is just a bunch of simple functions:

red :: String -> String
red s = "\x1b[31m" <> s <> "\x1b[0m"

green :: String -> String
green s = "\x1b[32m" <> s <> "\x1b[0m"

yellow :: String -> String
yellow s = "\x1b[33m" <> s <> "\x1b[0m"

blue :: String -> String
blue s = "\x1b[34m" <> s <> "\x1b[0m"

logSuccess str = green "[SUCCESS]: " <> str

logInfo str = blue "[INFO]: " <> str

logError str = red "[ERROR]: " <> str

logWarning str = yellow "[WARNING]: " <> str

Where to from here?

This is one of those little things that you're proud of and have fun tinkering around with. There are no goals other than just having fun while I improve the functionality and also keep it simple and useful enough.

Of the many side-projects I've worked on the years, this is one of those that I use regularly. That makes this project somewhat special.