Programming should be enjoyable
A software blog by Joseph Junker
Bridging the Object-Oriented and Functional Divide with the Visitor pattern
Adventures in extensibility
11 Feb 2023
The Church and Scott Encodings of Algebraic Data Types
Recursive data as pure functions
02 Jan 2022
Previously I wrote about the Church encoding of non-recursive algebraic data types. In this post I’ll cover the Church encoding of recursive data types, as well as the related Scott encoding. This post uses TypeScript, and will use the abbreviation “ADT” to mean “algebraic data type”, not “abstract data type”....
The Church Encoding of Simple Algebraic Data Types
Representing data as functions
01 Dec 2021
When first learning about the lambda calculus, students are frequently introduced to Church numerals and Church-encoded booleans. These enable the expression of simple data types as pure functions. When I was first learning about them these encodings felt arbitrary, because I did not understand that they were expressions of a...
An Introduction to Algebraic Data Types
Structured, concrete data
14 Mar 2020
In my last post I said that there were three fundamental approaches to representing data: abstract data types, objects, and algebraic data types. I introduced abstract data types and objects (using a strict definition of “object” based on autognosis) and showed the tradeoffs of implementing data structures in these two...
Abstract Data Types and Objects
Two fundamental approaches to data abstraction
14 Mar 2020
There are three main methods of representing data which developers are likely to encounter: abstract data types, algebraic data types, and objects. Abstract data types (frequently abbreviated “ADTs”) are likely familiar to developers with a computer science background, and algebraic data types (unfortunately also abbreviated “ADTs”) are likely familiar to...
My Medium blog
09 Mar 2020
The Problem with "Overengineering"
07 Mar 2020
I worry about using terms which have heavily overloaded meanings. In software discourse, “simple” and “complex” may be the most pernicious, and using them without referencing a specific definition is virtually guaranteed to cause misunderstanding and strife. In the same vein, I’ve recently developed an aversion to the term “overengineering”....