Thomas Cothran, Software Developer

Avoid with-redefs in tests

Mon, 07 Apr 2025 00:00:00 +0000

Advice to avoid with-redefs often focuses on the wrong things. It is true that with-redefs can cause race conditions in your test suite. And that functions can be captured in closures, leading to them not being redefined as one might expect. And that with-redefs doesn’t redefine inlined functions. And that with-redefs can cause problems with type-hinted functions. And that they cause problems when used with macros. And that mutating the global environment is something functional programmers should know is a bad practice. Etc., etc.

What do I want from a codebase?

Wed, 27 Nov 2024 00:00:00 +0000

Carson Gross’ “Codin’ Dirty” essay is designed to provoke controversy. Although I will critique the essay, I want to make it clear that I am (on this Thanksgiving eve) grateful for Carson Gross’s work.

Gross writes:

I’m … not trying to convince you to code dirty with this essay. Rather, I want to show that it is possible to write reasonably successful software this way and, I hope, offer some balance around software methodology discussions.

Bthreads: A Simple and Easy Paradigm for Clojure

Wed, 30 Oct 2024 00:00:00 +0000

Asynchronous programs are hard to reason about. But is this intrinsic to asynchrony? Or might we be using the wrong paradigms?

Behavioral programming is a programming paradigm that aims to make asynchronous, event-driven systems both simple and easy by using a system centered on behavioral threads (bthreads). In my previous article, I introduced the idea of behavioral programming in Clojure.

In this article, we dive deeper. I hope to convince you that, compared to the alternatives:

Behavioral Programming in Clojure

Tue, 24 Sep 2024 00:00:00 +0000

Behavioral Programming is a relatively new programming paradigm that excels at isolating and composing behaviors in event driven system. It is unrelated to behavior driven development.

Behavioral programming was invented by David Harel, who also invented statecharts in 1987. It uses independent units of behavior, called bthreads, which are coordinated in a pub-sub protocol.

How does it work?

A behavioral program will first collect the bids from all of its bthreads. A bid can do three things:

The Ocelot Game

Wed, 11 Sep 2024 00:00:00 +0000

The ocelot game works like this: a developer has written a feature, and presents it to an ocelot.

Not a real ocelot. Ocelots are playful. But they’re wild animals. Their claws easily poke holes in things. We want to poke holes in code.

The ocelot is a role played by a developer who tries to poke holes in another developer’s code. Specifically, they try to change the code in such a way that the feature breaks while still passing the unit tests.

Top-Down Imperative Clojure Architectures

Mon, 22 Jul 2024 00:00:00 +0000

When I first became interested in functional programming, a more experienced engineer told me: “you know functional programming doesn’t really amount to much more than procedural programming.” As I insisted on the benefits of map, filter and reduce, he simply shook his head. “You’re thinking in the small. Go look at a large real-world application.”

It took some time for me to see what he meant. My preferred language, Clojure, is a functional language. But too often it is used to build top-down, imperative applications. This negates the value proposition of functional programming: isolating side effects, local reasoning, and system composition.

MPAs vs SPAs: The False Dichotomy

Sun, 28 Jan 2024 00:00:00 +0000

This is the second post in the series “Have Clojure UIs Taken the Wrong Path?”. The first post is here.

How do we choose between building an application using a hypermedia approach versus the client-side SPA? This post won’t answer that question. But it will say how not to make that choice.

A common heuristic is the spectrum that stretches between old fashioned “Multi Page Apps” (MPAs) for basic use cases, to Single Page Applications for rich client interactivity.

Have Clojure UIs Taken the Wrong Path? Part 1

Fri, 24 Nov 2023 00:00:00 +0000

The Clojure community has focused on React-based solutions for complex front-end clients such as Reagent, Rum, Om, Re-frame, and Fulcro.

For all their differences, they follow a very similar architecture, making heavy use of client-side state and using RPC for client-server communication. We will call this the “React+” approach.

But is this the right choice?

I will suggest the answer may be negative. My suspicion is that as web UI libraries advance, the problems they solve are not essential. Rather, the problems are accidental; they are generated by the React+ architecture.

The Wrong Kind of Readability

Sun, 05 Nov 2023 00:00:00 +0000

In the Pragmatic Programmer, Andy Hunt and Dave Thomas tell us: “it’s critical that you write code that is readable and easy to reason about.” This seems uncontroversial; it is the rare point on which software engineers typically agree. Or do they?

In fact, developers disagree about what “readability” means. “Readability” can be given two contrary meanings that we will call imperative readability (or readability-i) and declarative-readability (or readability-d).

Imperative Readability

This form of readability focuses on how the code operates. It emphasizes a clear presentation of the implementation details, such as which libraries are used, how data sources are accessed, and how functions perform their tasks.

The Library Locker - An Antipattern

Sun, 20 Aug 2023 00:00:00 +0000

The “Library Locker” is a common anti-pattern for incorporating third party libraries into an application. The application wraps the library with its own function, which mixes concerns and makes the library more difficult to use.

In this article, we will first consider the original problem the library locker is introduced to solve, then an example of the library locker, and then suggest better alternatives.

The Problem

Suppose we have system of microservices that support astronomical applications. We locate our calls to our other microservices in a service directory.

Brittle Clojure: Creating Legacy Clojure Systems

Sun, 23 Jul 2023 00:00:00 +0000

This is the first in a multi-part series, “Brittle Clojure”. In this series, we will consider common patterns in Clojure which yield brittle systems, as well as methods to ensure robustness.

None of the basic principles for building robust software are unique. Most literature, however, is focused on object-oriented systems. Our point of view will sometimes zoom in to Clojure “in the small”, and sometimes zoom out to distributed systems built with Clojure.

Distributed Merges and Continuous Integration

Fri, 14 Jul 2023 00:00:00 +0000

Among DORA’s more controversial findings is that trunk based development is superior to feature branching.

Teams achieve higher levels of software delivery and operational performance (delivery speed, stability, and availability) if they follow these practices:

Have three or fewer active branches in the application’s code repository.

Merge branches to trunk at least once a day.

Don’t have code freezes and don’t have integration phases.

Since we know not to be Cremoninis, we won’t be distracted by whether trunk-based development meets the HN trendiness standard, and we’ll be skeptical of anectdotal appeals to experience

Don't Be a Cremonini

Sun, 09 Jul 2023 00:00:00 +0000

Differences of opinion about how we ought to write software have an air of the philosophical about them. Some prefer TDD and microservices, others may prefer monoliths and think that most testing is a waste of time. Or engineers may prefer to use continuous development methodologies, while businesses prefer a waterfall approach with decorative scrum ceremonies.

Are we stuck with opinions? Must we be subjected to the obligatory “well, in my experience …”? Are we simply expressing our personal feelings, or is there some truth to be had?

Haskell's Triangle

Mon, 17 Jul 2017 00:00:00 +0000

The polymath Blaise Pascal envisaged a triangle built of numbers. Pascal’s triangle — as it is usually called, despite the fact that its discovery predated Pascal by centuries — has the interesting property that each number is the sum of the two numbers directly above it.

In this post we will use Pascal’s triangle to demonstrate how recursion (i.e., a procedure that invokes itself in its definition) can be used to make complex problems easily soluble, using examples written in both Haskell and JavaScript. Wikipedia

Recursion Made Simple with Roman Numerals

Mon, 17 Jul 2017 00:00:00 +0000

A procedure is recursive if it invokes itself. Thus:

const toInfinityAndBeyond = num => toInfinityAndBeyond(num + 1);

Of course, toInfinityAndBeyond is only useful if, rather than seeking an answer, you want to blow your call stack. But you see the point: we find toInfinityAndBeyond in its own body. What possible use could this be?

Recursion is often well suited to express the logic of a problem. Let’s take a simple problem: the conversion of Roman to Arabic numerals. One solution is this one: