Thoughts on Functional Programming Podcast

Stratified design is one where you build more specific things on top of more general things, typically with many layers. But why is this powerful? In this episode, we explore why it’s sometimes easier to solve a more general problem than a specific one.

We often write software to automate an existing physical process. But what makes this possible? When translating from physical to digital, something must be preserved. In this episode, we look into what is preserved across that translation and why algebraic properties might help us find it.

Definitions of functional programming disagree with each other and often don’t encompass the broad range of languages and practices we find in industry. The definitions also make it seem incompatible with other paradigms, such as object-oriented and procedural. However, if you look at FP as a set of skills, both problems are solved. We can find skills that functional programmers tend to use and not be incompatible. In this episode, I explore some important, high-level skills that functional programmers employ.

Computer commercialization set research back decades and we still haven’t recovered. I explore why that is and end on some hopeful notes.

Through conversations, I’ve realized that there’s two kinds of data modeling that are distinct. They have their own constraints and needs and, consequently, their own techniques. In this episode, I explore what makes them different.

Product and sum types are collectively known as ‘algebraic data types’. These are two ways of putting types together to make bigger types. Product types multiply their states, while sum types add them. With these two ‘operations’, we can precisely target a desired number of states. In this episode, we explore how we can eliminate corner cases with algebraic data types.

I prefer Clojure to Haskell. It’s probably mostly due to accidents of history: getting in Lisp at an earlier age, spending more time with Lisp, and only having one Haskell job. But I do have some philosophical differences with the Haskell philosophy as it relates to Haskell as an engineering tool. In this episode, I go over four of them, and try to relate them with anecdotes.

Denotational Design is a abstraction design process created by Conal Elliott. I like it because it really asks you to step back and design the meaning of the abstractions before you implement them. In this episode, I talk about why I like it, what it is (step-by-step), and why it’s not about static types.

Business rules are different from your domain model. What goes where? I hope to tease apart this important yet subtle distinction in this episode.