mb21’s blog

On Change and Craft in Software Design

Sun, 13 Apr 2025 00:00:00 +0000

Software seems to be that mathematical thing that can be perfected and finished. But somehow this never works in practice. Why not?

We software developers keep struggling with that question. A lot of us instinctively want to write “beautiful” code and craft the “perfect” solution. Out in the real world, engineers may struggle with printers that jam, robot wheels that slip, machinery that gets worn down by use, or by harsh weather. Physical materials rot and decay, even when they’re just sitting there doing nothing – chemistry and time doing their thing. But in the virtual world, us software developers should be spared from these earthly troubles, right?

To a certain extent, yes. Software in the abstract sense really does not change. It’s just information after all – like text or mathematic formula. Pythagoras’ theorem is still the same after two millennia after all. (Yes, the hardware carrying the bits and bytes may wane. But through the miracle of digital technology and error correcting codes, we can copy those bytes over to the next generation of carriers without any loss of information.)

Software does not exist in isolation

But here’s the mistake I see a lot of us software developers make. We forget that no piece of software exists in isolation. While the software itself may be preserved unchanged, the world it’s interacting with does change.

Unless your software is a pure function, it is doing IO, system calls, network calls, etc. If you want to run your program a decade later, the underlying OS still needs to behave the same, and any networked computers your program relies on need to still be there.

And even if the technical environment remains compatible: your users change as well! An MS-DOS program might still be runnable in a VM, but users won’t like the UI anymore, especially on their smartphone.

Evolving tech ecosystems

Different tech ecosystems have different rates of change. Microsoft is famous for their backwards-compatibility, going even so far as to emulate old bugs in subsequent versions of Windows, so that old programs that relied on the previous behaviour would not break. Apple, in contrast, removes older APIs more aggressively, infuriating developers that need to change their apps if they want them to continue to run on the newest version of macOS or iOS, which is what most users will be running.

Changes on one level of the tech stack sometimes enable more frequent changes on the levels above. Back when software was printed on physical media like CDs, major versions of OSes with new features were released once every couple of years. Today, Apple may still announce the new features at its yearly WWDC conference, but they’re actually rolled out in point updates over the course of the whole year. And for websites like Facebook or Google, it’s not uncommon for new versions to be deployed multiple times each day.

Yet on the web, unless you were using Flash, your website from a decade ago still renders the same in modern browsers. However, “frontend” web developers have created an update-treadmill of their own: often relying on a baroque number of third-party dependencies, and building on top of frameworks that keep changing under their feet. While adopting newer and better technologies may make sense, the drive to work with the newest hip web framework often seems to be more similar to a fashion trend, or due to fear of being “left behind” in the job market (either as an employer or employee).

When choosing the tech ecosystem on which you build your application, one crucial factor is its rate of change, and whether you like the direction of that change. Do you prefer a stable platform that doesn’t require you to invest a lot of time to keep up with it, or do you believe valuable new functionality continues to be added to the platform, and that you have the capacity to make use of that? Are the users I want to reach on the platform or moving away from it? Will there be developers familiar with the platform available for hire, and will they have the other skills I require?

Change is uncomfortable

Make no mistake, change is uncomfortable. All else being equal, we humans prefer to stick what we know over taking a risk and investing time and energy in learning something new. Granted, us techies are generally more interested in new technologies. But it is a testament to how much beneficial technological progress we’ve been going through as a society, that so many of us are so often willing to take a bet on the next thing, assuming that it will bring us as much benefit as past innovations have done.

Innovation waves

New technologies are adopted in waves. If a new technology has a higher perceived advantage relative to its alternatives, it will be adopted more quickly. When a technology is new, it still changes quickly, as learnings come in and low-hanging fruits are picked. Later on, as the technology has matured and also more people and businesses rely on it, breaking changes become more expensive, and big improvements harder to achieve. The technology becomes entrenched. The cycle repeats and the next wave builds up when a new technology comes along that seems so much better, that it manages to overcome the ecosystem advantages of the existing technology.

Instigating change

As application developers, we are on the receiving end of change when it comes to the tech platform we build on. However, when it comes to the business we are building our product for, often we are the instigators of change. We want our customers to adopt our product, or the new version of our product. Suddenly, it’s us that need to walk the tight-rope between innovation and familiarity. It’s us that need to shepherd the ecosystem slowly forward, because “Being Too Early is The Same As Being Wrong”. And the path of innovation is always through the adjacent possible: each intermediate step needs to be advantageous, otherwise it’s not adopted.

Worthwhile change

You may long to build a product that lasts. This is easier in an established domain, since the broad strokes are clear and you can obsess over the details – you know the terrain that you want to find the maximum spot on. But if the domain is still moving and changing quickly, when you don’t know whether you hit a local maximum, because you don’t know the whole terrain yet, then you need to iterate on imperfect artifacts that evolve in symbiosis with the involved people and processes, so that the whole terrain can be discovered.

In that case, even if your technology or product was used only for a small time and was quickly obsoleted by the next wave – it was still a necessary step. Even though your particular piece was superseded, your lasting contribution was to move the field forward as a whole.

One example is in the field of aircraft design: the development of the Zero fighter, as portrayed in Miyazaki’s film The Wind Rises, where its creator says he did “the best he could with the time that was given to him”.

On craft and deliberate design

But just because a product’s shelf-live may be limited, that does not mean it shouldn’t be designed properly, and crafted deliberately and with care. It seems to me, that’s a largely orthogonal quality.

It’s true that some companies or teams move fast and carelessly (Facebook comes to mind). And established big corporations are famous for moving slow and carelessly: often they look at software development as a commodity to be de-risked, with managers not caring about the quality, as long as the widget is on schedule.

On the other hand, companies like Apple or Nintendo demonstrate that even big companies can have a culture that deeply cares about design. In an established domain like laptops, Apple is iterating slow yet deliberately: the newest MacBook looks the same like the ones that have come before it, but each iteration is slightly tweaked with updated hardware.

Finally, when entering a new domain, iterating quickly, the temptation may be strongest to cut corners. But you can still be deliberate in your design process, and decide carefully which corners to cut – which features you need now, and which can wait for a later iteration. That’s the definition of a minimum viable product, after all. The original iPhone may be one of the best known examples. When it launched, reviewers complained about the basic camera and an Email client that missed enterprise features. It was also later revealed that on the first version, all programs were running in sudo mode with elevated privileges – clearly a bad practice, but something Apple decided was okay to fix in a later software update, in order to focus on the features that made the iPhone unique, and get it out of the door in consumer’s hands now.

	carelessly	deliberately
moving fast, iterating quickly	Facebook	iPhone at launch
iterating slow in a mature domain	most big corporations	MacBook nowadays

A MPA, no-bundler JavaScript meta-framework separating client- and server-code

Sat, 13 Apr 2024 00:00:00 +0000

Modern JavaScript meta-frameworks like Next.js, Nuxt, Astro, SolidStart, SvelteKit and Qwik all use a bundler/transpiler (like Vite or Webpack), and with the exception of Astro and Qwik, all of them are SPAs.

I would love to have a modern JS meta-framework that does away with these two conventions, but instead chooses to optimize for simplicity and leveraging browser-built-ins over client-side JavaScript:

MPA over SPA. See the Single-Page App (SPA) vs. Multi-Page App (MPA) section of my previous blog post, but the gist is that for most use-cases, modern browsers can do client-side routing better than JS. This would also allow a simpler solution to what the Solid folks call the double data problem: that the complete template and associated data often ends up being sent to the client twice, as initial HTML and as JavaScript (because you may need it in JavaScript format for hydration or on client-side page navigation).
No bundler. Instead using browser-native Import maps and modulepreload links (i.e. the same approach that importmap-rails took). A very simple asset pipeline would still do two things: add a hash to the filename to enable long caching in a CDN, and converting TypeScript and JSX to plain JavaScript (TS and JSX now being so engrained in the ecosystem that it’s built into both Deno and Bun).

Why? I think that for most use-cases (i.e. if you’re not building the next Figma or Google Docs), this will provide both superiour UX and superior developer-experience.

A bundler (and related tooling) is just such a massive addition in complexity that the developer needs to understand in order to debug certain issues. It seems to be a historical accident (because bundlers have their roots in tooling for client-side-only SPAs) that lots of functionality is implemented in bundlers instead of in plain JavaScript functions, which you would call either during static site generation or during server-side rendering: like how import.meta.env is replaced in the build step and not accessing the env variable when you run the server, or how CSS or SVG files are included into a component. This makes it unnecessarily difficult to call the vite-based code, that you wrote to render some HTML on your webiste, in a script (e.g. in a cron job to send an email). Also, the newcomers to modern JS-tooling that Astro targets routinely struggle with what exactly the behaviour of <script> and <script is:inline> is (in addition to forgetting to add client:load to hydrate islands).

Finally, with the exception of Astro, all the modern meta-frameworks ship with some kind of RPC functionality that doesn’t make the network request explicit, and without forcing the developer to handle network errors: use server in React/Next.js and SolidStart, as well as server$ in Qwik.

And even in Astro, it’s very easy to accidentally bundle some big npm package, that you meant to use only on the server, into the client-side bundle. For example, this can happen if you just import a self-contained pure helper function into the client, and that function happens to be in the same file that imports some server code. That’s why I’ve started even in Astro projects, to name my files *.client.ts and *.server.ts. I’d like the framework to enforce such a rule:

Strict separation of client-side and server-side code. To make sure that server-code never accidentally ends up on the client.

The reverse, client-code running on the server, is sometimes needed (to server-side-render components), and is less problematic, since you will immediately notice if you try to access window on the server, because it will just crash.

With these three constraints set, I’m not sure what the best architecture would look like.¹

Do you know of any such framework and/or would be willing to collaborate on creating one? Feel free to open a mastro issue.

Explicit islands? But then you’re still sending the whole code of client-side components to the browser. We could do even better by just sending the interactive parts. ↩

Declaratively rendering components: HTML vs JS functions

Thu, 01 Feb 2024 00:00:00 +0000

I’m a big fan of the idea of declarative programming. Examples are HTML and functional programming.

But which of the following two approaches is more declarative when you’re rendering a bunch of components on your server, and your server happens to be running JavaScript?

Relying primarily on HTML, or
relying primarily on JavaScript functions.

Consider the syntax of declaring a component: an Astro component is primarily an HTML snippet:

---
const { title } = Astro.props;
---
<details>
  <summary>{title}</summary>
  <slot />
</details>

Whereas a React/Solid/JSX component is a JavaScript function:

export const Popover = (props) =>
  <details>
    <summary>{props.title}</summary>
    {props.children}
  </details>

Notice how child elements are passed to the component: in Astro you have to use a slot, similar to HTML’s slot element, somehow mimicking how a poly-fill for native web functionality would work. But we’re running on a server here and rendering HTML to a string that will be sent over the network. There is no DOM, and Web Components will never be implemented in Node/Deno/whatever. In React/Solid, child elements are simply passed as props.children – just like any other component prop.

I’m sympathetic to Astro’s argument of starting out with the least powerful tool in the toolkit, which is HTML, and later you might add some frontmatter containing JavaScript. It’s nice that non-developers can contribute and only need to write HTML.

But even in Astro, you won’t get very far without having to learn some JavaScript. Just passing some props to a component requires you to do that already (for the line const { title } = Astro.props). In templating languages like handlebars, partials all live in a global namespace, whereas in Astro you need to use JavaScript import statements to be able to include your component in another page. It feels like Astro components live in this weird middle-ground: they try to be usable without JavaScript knowledge, but fail to be so for the most basic cases.

In both Astro templates and JSX, we’re using a template system that’s embedded in its host language; meaning you can use arbitrary JavaScript syntax within the template, like .map and condition ? exp1 : exp2 instead of {{for}} and {{if condition}} exp1 {{else}} exp2 {{end}}).

Considering that, the answer may very well be be that leaning on JavaScript as much as possible (i.e. approach 2), requiring the developer to learn fewer different concepts, is the better approach. After all, functions are just such great abstractions, when used well. Meaning the React/Solid folks got it right. An argument I tried to make over on the Astro discussion board.

Wanting to explore this thought here a bit more, I pushed some code to GitHub: mastro – a minimal, no-dependencies take on an experimental Astro-like web framework.

The right mental model for Git

Wed, 13 Dec 2023 00:00:00 +0000

This post was prompted by Julia Evans ruminations on Mastodon while she was working on a tutorial zine about the version control system Git. In particular, I posted a rough version of this post in this thread but wanted to flesh it out here.

While (almost) everyone agrees that the user-experience of Git's command-line interface is terrible (there are a lot of confusing names to memorize, and any one command does a lot of different things), people disagree on whether the underlying concepts of Git are intuitive or not. I happen to be one of those people that are perfectly happy thinking of a Git repository as a DAG (Directed Acyclic Graph) of commits.

While I'm not claiming this is 100% right, the following mental model of Git has served me very well:

A commit is identified by a hash (e.g. 84ecff443c07dd3c7e8a3b6cee5a0fd51dc7f891), which is computed from:
1. a diff of all the changes,
2. the commit message,
3. a parent pointer (which is just the parent commit’s hash).
By following a commit's parent pointers recursively and adding all the diffs from the beginning, a snapshot of your files at any point in the history can be reconstructed. (Implementation-wise these snapshots surely are cached, because otherwise things would be very slow, but that’s best seen as an implementation detail.)
A branch (e.g. main) is a named pointer to a commit. The pointer is often automatically moved along (e.g. when adding new commits to a branch).
A merge commit has two parent pointers, which makes them a bit hard to work with.
There are various git commands that are known under the term rewriting history (e.g. git rebase, --amend, etc). However, these commands don't modify a commit (which is impossible, since that would change its hash). These commands actually create new commits from old ones, and then point the branch to the last new commit.

The old commits are usually orphaned by that operation – meaning they’re not reachable by following the parent pointers of any branch. But you can still find orphaned commits via git reflog – until they’re garbage collected.

Rewriting history and then pushing the change to a remote branch (e.g. on GitHub) requires a force-push. You should only do that if you know what you’re doing, and should never do that if others already have started work based on that branch, as that would leave their local branch in an incompatible state with the remote branch (their parent pointers would point to commits that no longer exist).
A remote (e.g origin) is a shortname for a url (e.g https://github.com/my-user/my-repo), with the url locating a remote repository (often on GitHub). git fetch downloads commits from that url into a local branch (e.g. origin/main), which can then be merged into a normal local branch (e.g. main). git pull does git fetch followed by git merge.

The bad news is that there are more Git concepts than just these (such as ssh keys, tags, stashing, merge strategies, etc). But keeping this mental model in mind should keep you mostly sane.

While I had the (mis-)fortune to just bite the bullet and learn git on the commandline, I've heard good things of GitUp (if you're a mac user) and Magit (if you're an emacs user). Finally, if you just want something simple and stupid, GitHub Desktop works fairly well (you might want to start with this 20min video).

Building a Modern Website? SSG vs. SSR, SPA vs. MPA, Svelte vs. Solid

Mon, 18 Sep 2023 00:00:00 +0000

You wanna build a modern website? Okay. Assuming you have no baggage (like existing know-how with PHP, Ruby on Rails or similar), you most likely go with the one programming language that not only runs on servers, but also in the browser: JavaScript. Or more accurately, assuming you believe in statically-typed languages (discovering bugs already at compile-time, types as documentation, easier refactoring), you go with TypeScript.

(If you won't ever need rich interactivity in the browser, or you're fine with learning two programming languages and stacks, you can of course also choose something else then JavaScript to run on your server, and use a bit of vanilla JavaScript or HTMX to add some limited interactivity.)

Static-Site-Generation (SSG) vs Server-Side-Rendering (SSR)

If you have an ordinary website with less than a couple thousand pages, go with Static-Site-Generation (SSG). It's simple. You don't have to run a server: that means no server to harden against load spikes or attacks, it's basically free, and out-of-date dependencies aren't really a security issue. Put up a repository on GitHub and connect it with Netlify or Vercel. Whenever somebody edits or adds a new page (either by editing a markdown file on GitHub, through Decap CMS, or through a headless CMS), a new build is triggered, the whole website is regenerated and its static HTML, CSS (and perhaps JS) files are uploaded to some CDN.

Unless regeneration of the website is taking too long for you, there is rarely a reason to not stick with SSG. (Except if you have other fancy requirements, like serving different HTML to different users and you cannot just customise that with some JavaScript on the client after page-load.)

If you need your users to submit a form, or you need to add a few other dynamic features, you can always add a "serverless function" (fancy-speak for an AWS Lambda function) or an "edge function" (fancy-speak for a Cloudflare Worker or similar) and usually you'll be fine.

But perhaps you have millions of pages, so the regeneration takes longer than a few minutes. Or perhaps even three minutes is too long for you, since you want to publish breaking news. Or perhaps your many authors update the content so often, or your developers update the code so often, that the couple of minutes of generation time are just too annoying to put up with every time.

Then perhaps, it's time to consider Server-Side-Rendering (SSR). Each page is generated on-demand, only when the user requests it from the server. You can do that with "serverless functions" (although currently AWS Lambdas don't support HTTP streaming), or "edge functions" (although you'll have a long round-trip-time from the edge to the central database – if you have one – so you benefit little from running on the edge close to your users). Or you can go fully old-school and do what everyone did in the PHP and Ruby days: just run a server. Nowadays it's running somewhere in the cloud (on render.com, fly.io, or just AWS or Azure) – and you can scale horizontally and add more servers once that's needed – but the principle is fundamentally the same. And it's still a great option.

Interlude: the pendulum of technology

If you've been around building websites for a couple of decades, you may know that static-site generation is a terribly old hat. In the first days of the web, that was in fact the only way to build a website: you would just upload your static files via FTP to some server. And some folks, that were fed up with having to change the header and footer in all their HTML files whenever it needed updating, they even cobbled together bash scripts to do static-site generation – even though it wasn't known under that name at that time. Of course, once servers gained the ability to run PHP, almost everyone switched to doing that (and thanks to WordPress and its ilk, a lot of websites are still server-side rendered with PHP). Until static generation came back again with static-site generators like Jekyll, which is still the default for GitHub Pages.

And that's the way it is with a lot of technologies: the pendulum swings back and forth between two extremes as time goes by. Some of it is just fashion. Some of it is also driven by technological constraints at that moment. And these things influence each other: the more people think of a certain approach or technology as "hip" or "state of the art", the more resources will go into improving that. Until other people start to think of it as a dead-end and will start working on a different approach, sometimes taking into accounts the lessons from the past, sometimes less so. And thus the pendulum starts to slow and eventually swing back.

Another example is the pendulum swinging between where the majority of the work happens: on the client or on the server. For a time, you had mainframe servers that did the heavy lifting, with thin clients/terminals attached. Then came the personal computer, which shifted work back to the client (the desktop PC). Then came the World Wide Web, and later the cloud, and shifted work back to servers. Meanwhile, with the advent of lots of JavaScript/AJAX in websites and native apps in iPhones, the GUI shifted back to the client for a while, with the server relegated to just providing a JSON API to sync up the data.

Single-Page App (SPA) vs. Multi-Page App (MPA)

For some time, in the early 2010s, people would go even so far as to not have the server render any HTML, but just serve a blank page with a bunch of JavaScript that would then render the GUI, and even take over the task of page navigation from the browser: the quintessential SPA. By 2020, people realized that serving a blank page gave users a slow initial page load, so the first page was server-side rendered in Next.js and similar frameworks. But on page navigation (when a user clicks a link), the whole code for the next page needed to be downloaded and run in the browser after all.

This is not the case with React-Server-Components (RSC) and Next.js App Router anymore. There, server-components are rendered on the server and then the JSX is serialized and sent over the wire.

But the definitional feature of a SPA remains: the browser loads only a single page, later page navigations are simulated with JavaScript. That’s called a client-side router, and it has to reimplement browser features like loading indicators, scroll restoration on back navigation, which adds to the JavaScript bundle size, and never works quite the same. And it definitely doesn't work while the browser has already rendered the initial HTML, but the JavaScript hasn't executed yet.

The idea of a SPA is that you’re trading upfront page load time with a better user experience later on. You don’t need to reinitialize everything after a page navigation. And arguably, SPAs have better page transitions than browsers used to have.

But guess what; browsers have improved since and the balance has started to shift away from SPAs again. Modern browsers have no flash of white between pages anymore, they have back-forward caching and service workers for offline functionality, etc.

There are still some use-cases that can only be realized in a SPA, like playing audio or video during page navigation, or otherwise keep state in the DOM (like cursor position) that cannot be easily persisted in localStorage. And if you need any of this, because you're building the next Figma, then absolutely, go with a SPA.

But for most cases, I would just do a MPA, profit from the reduction in JavaScript bundle size, let the browser handle what is was built to do: page navigation, scroll restoration, page caching, streaming in HTML – and an HTTP GET that returns HTML is way easier to debug than RSC's stream of JSX. Finally, RSCs are currently only available in Next.js's App Router – which is production-ready in name only as of 2024. Meanwhile, Astro is a MPA-framework in version 3.0 today, that brings everything you’d expect from a modern framework: components, CSS modules, TypeScript, etc.

(If you don't do a classical SPA, you don't have to build a dedicated REST or GraphQL backend which would need to be secured and maintained – just query the database directly in your server code. Especially when you're still small, and don't have separate backend and frontend teams, this is a huge time-saver.)

Svelte vs. Solid

At some point, there comes the time for your project to add some client-side interactivity that goes beyond what can be reasoned about in vanilla JavaScript; when you need to maintain some state and keep the GUI synced with it. In Astro, you can place islands of client-side interactivity in the server-side rendered page. Islands can be implemented in any of the popular client-side GUI frameworks like React, Preact, etc. And obviously only the islands' JavaScript needs to be downloaded to the browser. To share client-side state between the islands, you can use a library like Nano Stores or just use Solid signals.

Now you need to choose a GUI framework. Let’s say you bring no baggage, like existing know-how in React (which still has the biggest market-share) or similar. Or you're looking to learn something new. You want it to be fast and small. I would argue then you only have to choose between Svelte and Solid.

(And perhaps Qwik, which I haven't evaluated deeply. Definitely cool that they claim to be viable solution for both SPAs and MPAs. But if you've decided to go for an MPA already, then I'd trust Astro Island's explicit separation between client and server code a bit more than Qwik's approach where one developer's mishap might inadvertently pull in lots of code and even secrets into the client-bundle.)

Both Svelte and Solid are truly reactive frameworks (unlike React), meaning when something changes, not the whole component is recomputed, but a dependency-graph is followed, to figure out what exactly needs to be updated.

Solid's syntax is almost the same as React. You're just writing const [count, setCount] = createSignal() instead of const [count, setCount] = useState() (having separate getter and setters is called Read/Write Segregation and enforces unidirectional flow).

Svelte uses a compiler for reactivity, adding some JavaScript to each component, whereas Solid ships a small runtime and reuses that in each component. Therefore, for small apps Svelte has smaller bundle size but for a bit larger apps, Solid quickly takes the lead.

Svelte uses the bit weird $ label to mark up reactive regions, which the compiler then transforms, whereas in Solid the reactive system is just a library. It's just JavaScript all the way down – except for JSX, which is the only thing compiled in Solid (although there are a few transformations happening in the JSX that you have to get used to). Solid's approach also means that the reactivity graph is debuggable at runtime.

An area where Svelte shines is great out-of-the-box support for animations, and it can support those better with component lifecycle hooks.

Considering all the above, for most use-cases, I would personally choose Solid.

Conclusion

So there you have it. Here's my advice: for the most common cases, build a statically-generated Astro MPA with some Solid islands. Feel free to disagree.

An example of Algebraic Data Types in Swift, Kotlin, Rust and TypeScript

Sun, 10 Apr 2022 00:00:00 +0000

This post contains a simple example of using algebraic data types in Swift, Kotlin, Rust and TypeScript. The example is the following:

Define a product type User.
Define a sum type State.
Implement a pure function render that pattern-matches on the sum type.
Call render with a state containing a user and print the resulting string.

Swift

See also the nice blog post Algebraic Data Types in Swift.

struct User {
    let email: String
    let name: String
}

enum State {
    case loading
    case loggedOut
    case loaded(User)
}

func render(state: State) -> String {
    switch state {
    case .loading: return "..."
    case .loggedOut: return "Please log in..."
    case .loaded(let user): return "Logged in as \(user.name)"
    }
}

let user = User(email: "me@gmail.com", name: "me")
let state = State.loaded(user)
print(render(state: state))

Kotlin

data class User (
    var email: String,
    var name: String
)

// by sealing the class, the compiler will know all subclasses
// and can thus warn us about non-exhaustive pattern matches
sealed class State {
    object Loading: State()
    object LoggedOut: State()
    data class Loaded(
        val user: User
    ): State()
}

fun render(state: State): String {
    // still, exhaustiveness checking only works if the
    // `when` is used as an expression, like here
    return when (state) {
        is State.Loading -> "..."
        is State.LoggedOut -> "Please log in..."
        is State.Loaded -> "Logged in as ${state.user.name}"
    }
}

fun main() {
    var user = User("me@gmail.com", "me")
    var state = State.Loaded(user)
    println(render(state))
}

Rust

#[allow(dead_code)]
struct User {
    email: String,
    name: String
}

#[allow(dead_code)]
enum State {
    Loading,
    LoggedOut,
    Loaded(User)
}

fn render(state: State) -> String {
  match state {
      State::Loading => "...".to_string(),
      State::LoggedOut => "Please log in...".to_string(),
      State::Loaded(user) => format!("Logged in as {}", user.name)
  }
}

fn main() {
    let email = "me@gmail.com".to_string();
    let name = "me".to_string();

    let user = User { email, name };
    let state = State::Loaded(user);

    println!("{}", render(state));
}

TypeScript

type User = {
  email: string;
  name: string;
}

type State = 'loading' | 'loggedOut' | User

// it's important to put a return type here,
// otherwise exhaustiveness checking will not work
const render = (state: State): string => {
  switch (state) {
    // js switch can only match on primitive types like strings
    // in this example, we can abuse default case to reach the User object
    case 'loading': return '...'
    case 'loggedOut': return 'Please log in...'
    default: return `Logged in as ${state.name}`
  }
}

const state = { email: 'me@gmail.com', name: 'me' }
console.log(render(state))

Or more explicitly (but slightly more verbose):

type User = {
  email: string;
  name: string;
}

type State =
  { type: 'loading' } |
  { type: 'loggedOut' } |
  { type: 'user'; user: User }

const render = (state: State): string => {
  switch (state.type) {
    case 'loading': return '...'
    case 'loggedOut': return 'Please log in...'
    case 'user': return `Logged in as ${state.user.name}`
  }
}

const user = { email: 'me@gmail.com', name: 'me' }
const state: State = { type: 'user', user }
console.log(render(state))

A Categorization of Programming Languages

Sat, 18 Sep 2021 00:00:00 +0000

There are many ways to categorize a given set of things. I find it useful to place today’s major general-purpose programming languages (and then some I added because I find them interesting) in three dimensions:

x-axis: type system – from weak dynamic typings, progressing to strong dynamic typing (which doesn’t make that much of a difference) on the left, to compile-time checked static typings like C and Java and finally much more expressive static typings like Hindley–Milner type systems on the right.
y-axis: degree to which a language is conductive to writing code in a functional style – from not at all (imperative paradigm) at the bottom, to multi-paradigm languages in the middle and finally purely functional languages at the top.
color-code: of all the languages shown, only three have no runtime-overhead due to garbage collection: C, C++ and Rust. (Swift is using ARC, which is not strictly speaking garbage collection, but still comes with some runtime overhead.) The others either target a common runtime system (JVM, .NET, Erlang runtime), have their language-specific runtime (JavaScript or compile-to-JavaScript, Python, Ruby, PHP), or bundle the runtime with each binary (Go, Haskell).

Of course, these are only what I find are the three major technical considerations. When picking a language for a specific project, there are also a lot of soft factors to consider, like community and ecosystem, experience of the team, etc.

Composable Abstractions in Practice

Sat, 11 Sep 2021 00:00:00 +0000

This is the final part of a four-part series:

Part 1: What is functional programming?
Part 2: Pure functional programming and shared mutable state
Part 3: Pure functional programming in JavaScript
Part 4: Composable abstractions in practice

All programming can be seen as coming up with abstractions and using them to build even higher abstractions.

This pyramid of abstractions can be seen on the system level (hardware > operating system > application), but also in the evolution of programming languages themselves. I've picked four representative languages, each one at a higher level of abstraction than the previous one:

x86 assembly: consistent interface to different CPUs with different microarchitectures
C: eliminating manual register management and introducing loops in favour of jump/goto
Java: garbage collector instead of manual memory management and eliminating goto completely
Haskell: immutable data structures instead of stateful memory and map/recursion instead of loops

Functional programming offers the insight that simple functions are great abstractions.

What is abstraction

The process of abstraction is removing things (e.g. concrete implementations), so only the essential idea remains (exposed). The result of this process is also called an abstraction.

A good abstraction hides complexity behind a simple interface.

Sure, at some point every programming abstraction breaks down and the underlying implementation's characteristics leak through. But if it's a good abstraction for what you're trying to do, this happens relatively rarely. And while it doesn't, the programmer's mind only must keep the simple interface in his or her head – e.g. when calling a pure function, you usually only need to care about its interface, not its implementation.

If done right, the underlying abstractions don't (need to) change as often, so they can be carefully built and tested once. Higher-level code, which implements more specific things (e.g. business requirements), can then be easily changed more frequently.

Good abstractions compose well

Programming consists of decomposing your problem recursively into smaller and smaller sub-problems. As your experience as a programmer (or your projects's scope) grows, you'll see similar solutions pop up again and again to only slightly different problems. You can then tease out what these solutions have in common, extract that, and hide it behind a more general abstarction. By giving the abstraction a name, it can be reused again and again.

It’s true that the more general an abstraction is, the more widely it can be reused. But the most general abstraction is no good if it isn't simple to use for a specific use-case. (It's easy to create a very general function by just having it take lots of arguments, but that's hardly hiding complexity behind a simple interface.) If a function hides a lot of complexity behind a simple interface, it does it’s job – even if it’s only used in one other place in the codebase. Yet too often, programmers try to come up with abstractions that are too general, and end up with something that’s not composable and not simple to use.

Good abstractions compose well – like Lego bricks. Or like adding two integers alwyas yields an integer again (unlike pesky division).

In order to facilitate building your solution up from sub-solutions, good abstractions expose consistent and composable interfaces – meaning that the abstractions that live at the same level in your sytem, should be easily composable to build the next higher level. Think of how neatly Lego bricks always fit together to build bigger structures. The crazy thing in programming is that you can build shipping containers using Legos – and then you can continue to do the same thing at the next level and stack whole shipping containers to build a house.

Functional thinking in practice

As explained very well in Eric Normand’s Grokking Simplicity, functional programmers divide all code in:

data
calculations (pure functions)
actions (impure functions)

Data can be composed very easily (e.g. numbers can be added, strings and arrays can be concatenated, and maps can be merged). Pure functions are harder to compose than simple data, but not as hard as impure functions. Impure functions are more general than pure functions, but because you always have to worry about side-effects and order of execution, they are less composable.

That’s why functional programmers prefer data over pure functions, and they prefer pure functions over impure functions.

Composable abstractions in practice

If I had to come up with a list of the most important abstractions that functional programmers use in practice, it would be this list of simple yet extremely powerful abstractions:

Data is modelled with algebraic data types (Ideally, the programming language supports pattern matching on those data types, meaning that the code branches (think if/else or switch) depending on the shape of the data that’s matched on.)
Calculations are modelled using pure functions and actions are modelled using impure functions. If the behaviour of a function needs to be more configurable, often the best way to do so is to have it take another function as an argument. It’s then a higher-order function. (For this to work, functions need to be first-class citizens in your programming language.)
A programming language’s syntax is an abstraction over assembly. Unfortunately, a lot of current programming languages have both expressions and statements. While expressions can be endlessly nested, combined and composed to form bigger expressions, statements can only be combined sequentially using the semicolon. That’s why functional programmers favour expressions over statements.
Generics are used to make both data (Array<T>) and functions (identity: (a: T) => T) polymorphic, providing an easy way to generalize a given abstraction if it works the same for different types anyway.
Mathematical algebraic structures are a powerful way of thinking about, and generalizing over, a diverse set of structures we encounter routinely in programming. One of the most ubiquitous ones are monoids.

Pure functional programming in JavaScript

Sat, 23 Jan 2021 00:00:00 +0000

This is the third part of a four-part series:

Part 1: What is functional programming?
Part 2: Pure functional programming and shared mutable state
Part 3: Pure functional programming in JavaScript
Part 4: Composable abstractions in practice

In the first part of this blog series, we looked at the functional programmimg style with some examples given in JavaScript. In the second part, we looked at pure functional programming and why shared mutable state is the root of all evil. In this third part we look at what pure functional programming can mean in JavaScript.

React.js

By using React.js’s state handling functionality (useState, useReducer), you also mostly avoid shared mutable state. Every mutation of state is only applied on the next re-render, so for the duration of the current rendering cycle, there is no mutation of shared state. If you need side effects (to modify state outside React), you use useEffect.

Do pure functions exist in JavaScript?

Arguably, in JavaScript there are no pure functions, since basic building blocks of the language can be tampered with between function calls. For example the Array.map prototype can be polluted, making any function that uses .map return something else than it did before the tampering.

But as long as you have an agreement among all programmers working on the code to not do such crazy things, the notion of a pure function is still useful in JavaScript.

Mutable reference arguments

Previously, we said that “a pure function’s return value is the same for the same arguments”. But we didn’t specify a definition of “same”.

Object reference equality seems a bad definition (since e.g. [] === [] is false), but using something like lodash’s _.isEqual seems to be useful in practice (even if not perfect). Now, in most programming languages it makes perfect sense that if a function takes a mutable references as an argument, it cannot be pure, since another thread might modify the data structure while our function is running. In JavaScript’s single-threaded environment however, as long as your function doesn’t use any asynchronous code, this actually cannot happen.

Immutability in practice

JavaScript doesn’t ship with immutable data structures, but you might think of:

libraries like Immutable.js that used to enjoy some popularity, but it's not the same thing as having support built right into the language, since it adds some overhead (both syntactical and in terms of dependencies).
you can use Object.freeze, but you have to remember to write that everywhere you create a new object and it’s shallow (the freeze doesn’t affect nested objects).

However, you can write pure functions relatively easily by using the spread syntax to create a shallow copy of an object or array, instead of modifying the argument your function received. Modifying a deeply nested object may still be tempting, but would of course make your function impure.

Performance

Because making lots of new objects can be expensive in JavaScript, in rare cases, you may also want to forgo purity simply due to performance reasons. (But beware of premature optimization!)

These functions still don't do any I/O and they don't access non-local variables. But they may modify the objects given to them as arguments. It is then the caller's responsibility to take those modifications into account, or to not use the references to those objects anymore – which in the absence of Rust’s borrow checker, is of course a lot easier said than done and can be the cause of bugs.

Pure functional programming and shared mutable state

Sat, 23 Jan 2021 00:00:00 +0000

This is the second part of a four-part series:

Part 1: What is functional programming?
Part 2: Pure functional programming and shared mutable state
Part 3: Pure functional programming in JavaScript
Part 4: Composable abstractions in practice

In the previous post, I talked about four key concepts of functional programming. Pure (or purely) functional programming adds a fifth one:

Use pure functions wherever possible. And where interaction with shared mutable state is necessary, make it explicit.

(In fact, in a purely functional programming language, there are only pure functions.)

A pure function has both of the following properties:

Its return value is the same for the same arguments
(no reading of shared mutable state)
Its evaluation has no side effects
(no writing to shared mutable state)

Thus a pure function behaves like a mathematical function. This means you can replace the function call with its result without changing the behaviour of your program (this property is called referential transparency).

A function has a side effect if it modifies some state outside its local environment – i.e. calling the function has an observable effect (to the caller) besides returning a value.

Shared mutable state is a bit of a mouthful, so let’s break it down:

state is some data that is persisted over time. (A stateful system remembers previous events or user interactions.)
state is mutable if it can be modified.
state is shared if multiple parties can access it concurrently. (e.g. multiple programs accessing the same file, or multiple parts of a program accessing the same memory location)

It should be clear now that the notions of “pure/impure functions”, “side effects” and “shared mutable state” are three aspects of the same concept.

The root of all evil

Shared mutable state is believed by many to be the “root of all evil”, or at least the cause of most of the accidental complexity in our code. And “Complexity is the root cause of the vast majority of problems with software today.” (from Out of the Tar Pit)

Shared mutable state makes code unpredictable, hard to reason about and hard to test. It’s bad for the same reason global variables are bad. Data should be kept as local as possible and side effects should be avoided.

Finally, if you add concurrency to a program making use of shared mutable state, you easily get race conditions.

Two kinds of shared mutable state

Shared mutable state can be divided into two categories, depending on where it is persisted:

the world outside the program
the program’s own memory

Interacting with the outside world is generally called I/O (input/output) and includes writing to (or reading from) a file, a database, a network, etc. Most programmers are on some level aware that these things represent a form of external state (which is obviously shared and mutable), and the danger this entails. (For example cache invalidation is arguably just a special case of mutating shared state.)

Relatively few programmers on the other hand appreciate the danger of different parts of your own program being able to modify the same memory location. Hearing it phrased like this, many will say that in most programming languages at least we don’t have pointers any more, and cannot access arbitrary memory locations by address like you can in C. But having references to shared memory locations (and being able to write to them), is only a slight improvement.

Since any real program eventually needs to interact with the outside world, I/O cannot be avoided completely. But we can try to write as much as possible of our program in pure functions (especially the tricky parts like business logic that need to be tested and reasoned about), and clearly separate those from the parts of the program that does the necessary I/O.

The following mitigation techniques exist to the two problems:

code that does any kind of I/O is explicitly marked as such. (Using an IO monad or other effect system. This is somewhat similar to how the async keyword works in JavaScript.)
concurrent mutation of shared memory is prevented by either:
1. using immutable data structures
2. having mutable data structures that are not shared
In purely functional programming, immutable data structures are used almost exclusively. The Rust programming language’s “borrow checker” is a notable implementation of option 2.

Continue reading the last part in this blog series.