Thoughts on Functional Programming Podcast by Eric Normand

In this episode, I introduce the stratified design lens, which talks about how and why we split things into layers.

In this episode, I introduce the time lens, and I posit a law about representing time in complex domains.

In this episode, I introduce the volatility lens, which seeks to help us write code that deals with a changing world.

In this episode, I introduce the architecture lens, its questions, and its goal of modeling architectural domains to manage complexity.

In this episode, I introduce the executable specification lens, its questions, and its goal of getting to runnable, testable code as quickly as possible.

In this episode, I introduce the composition lens, its questions, and its goal of figuring what's true when you perform multiple operations in a row.

In this episode, I introduce the operation lens, its questions, and its goal of capturing the use cases of your software.

In this episode, I introduce the data lens, its questions, and its goals of capturing relationships among data values in data.

In this episode, I introduce the domain lens, its questions, and its goal.

In this episode, I compare executable specifications to UML, DDD, and software design.

I've found a better title for my book: Executable Specifications. Listen to find out why it's better.

I'm organizing my new book in terms of lenses. Each lens focuses our attention on one important aspect of software design. In this episode, I briefly introduce each lens.

I talk about the progress I've made on my book and why I'm throwing it away and starting over.

I give another reason why I don't encounter so many type errors in Clojure.

Watch the creation of a simple refactoring to turn functions into data.

One important skill in domain modeling is learning to see the semantics of your language, past the habits you've developed. To do that, it helps to see the same example in multiple languages. So how do I show examples in multiple languages without expanding the size of my book?

An isomorphism is a one-to-one mapping from two sets, and encoding your domain model involves finding a mapping between the real world and your code. So does domain modeling involve isomorphism?

Domain modeling also works after you've already got lots of code. How can we apply domain modeling analysis to existing data structures?

We discuss the commutative property, why we use it, and three different possible meanings.

We look at several examples where the associative property gives us expressive power.

We describe a three-step process for discovering conceptual models.

I discuss the closure property, which creates operations that can be nested. It's one thing that makes an API feel like a DSL.

What do I mean by algebra? And how do we get from level 0 to level 3?

All sophisticated models need to include time. We discuss two main ways to do that.

It is easier to reason about total functions. And you can make any pure function total using three techniques!

Mutation functions let you represent changing state over time. They are easily reified, used as reducing functions, and can operate on nested data.

Signature-Driven Development means starting with function signatures before you implement them. I also discuss why we implement the hardest function first.

I wonder when to deal with business rules. Do they belong in the domain layer?

I answer a listener's questions about whether domain modeling is a skill that can be taught.

We explore why focusing on the domain model can improve your software quality.

We talk about how you can evaluate the two parts of a domain model.

In this episode, I talk about the three-part model of domain modeling and what it means about how they are used.

In a domain model, when should we refer to things by name, and when should we nest a subcomponent?

When do we use collections in domain models, and how do we think about the states they represent?

In this episode, I talk about the three parts of my book, which mirror the three levels of domain modeling.

I talk about the advantages of writing a spec directly in your production language.

In this episode, I continue the exploration of the definition of domain model to serve as a base layer of understanding to write my next book.

We've all heard the term _high-level language_. Initially, it referred to the step from assembly languages to compiled languages. But it has another definition, which has to do with how well the language lets you think.

How is Smalltalk so small? Four rewrites.

I explore a new perspective about what abstraction means and how it can cause problems.

Why does some design advice work for some people, but not for others? And why do some agile practices work for some people, but not for others? I call that The Christopher Alexander Effect and explain how it works.

Can't we all just get along?

In this episode, I excerpt from and comment on Allen Newell's and Herbert Simon's 1975 ACM Turing Award Lecture.

Technical debt is a metaphor used to explain the tradeoff we all face when we have a deadline. How much is it worth to rush the code out the door? It's a good metaphor, but the term is often used these days to mean 'code I don't like'. In this episode, I examine the parts of the metaphor and ways in which technical debt differs from financial debt.

I explore why clean code is a lagging indicator and how the domain model is a leading indicator of maintenance cost.

I begin exploring the process of domain modeling with a definition.

I read from the 1974 Turing Award Lecture by Don Knuth.

We read and discuss the 1973 ACM Turing Award Lecture by Charles W. Bachman.

We read from and comment on Edsger Dijkstra's 1972 Turing Award Lecture called The Humble Programmer. Is the problem with programming that we don't recognize our own limitations? We'll explore that and more.

Do abstract and general mean the same thing? I don't think so. I've actually stopped using the term 'abstraction' because it's so laden with semantic baggage. We explore what they do mean in different contexts, and why abstract is not a relative term.