Programmers often arrange boolean expressions in all kinds of groupings for readability. The semantic of these groups, however, is not readily apparent to programs and algorithms. It turns out we can have it both ways, boolean expressions can be algorithmically normalized to consistent depth and form.

I recently learned of dependent type systems. I’m trying to feel out the boundaries of dependent types and came to the question: Is Clojure Spec a dependent type system?

I’ve been thinking about constrained values, and how those constraints could be used to better test our systems. Mark Seemann was gracious to think through this with me and point out some interesting conclusions.

I’ve been exploring ways to leverage type-driven development and value constraints for better testing. Turns out this has already been done, and there is a whole category of proof-oriented programming languages.

Turns out private members of C# records affect value-based equality.

Representing constrained values with types greatly reduces defensive programming. However, constraints make some values invalid, and constructors don’t allow for flexible return types like a failure state. Here’s an approach to constructing constrained values without relying on exceptions.

Dependency Injection has gained popularity in recent years. This is good, but Dependency Injection does not enjoy the full benefit of Dependency Inversion perscribed the the SOLID principles. This post will clarify the difference and some of the addition power enjoyed by Dependency Inversion.

I’ve struggled with explaining Service Locator as an anti-pattern. I’ve addressed certain cons of service locator and pros of constructor injection. However, I think I overlooked a fundamental misconception that would reasonably push developers away from constructor injection: a belief that constructor injection exposes dependency chains across the system.

This series is about design process and organizing our thoughts for effective development. The main goal is to establish a mental model and intuition for effective design process. This post reviews what we’ve learned.

This series is about design process and organizing our thoughts for effective development. The main goal is to establish a mental model and intuition for effective design process. This post explores questions to clarify thoughts in specific software lifecycle stages.