Programming should be enjoyable

JavaScript and TypeScript developers often look down on the original Gang of Four design patterns as irrelevant. Some (though not all) are rendered unnecessary due to the flexibility that JS provides over C++, and TS preserves most of the relevant flexibility. This post focuses on one of the patterns which...

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”....

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...

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...

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...

I previously did my blogging on Medium. I plan to convert my old blog posts from JavaScript+Flow to TypeScript, and move them here. In the meantime, though, here are links to most of my older posts: On functors: (prelude to inevitable monad tutorial) A Short Introduction to Functors An Introduction...

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”....