episode-code-samples: Point-Free's Swift episodes as a numbered archive

An archive indexed by episode number

The repository is the home of code written on episodes of Point-Free, and the README also says that if you want to ask a question, you can start a discussion.

The organisation is deliberately literal. Every episode gets a directory named after its number and its title slug, and the README is a numbered index into them. The first entries read:

0001-functions/
0002-side-effects/
0003-styling-with-functions/
0004-algebraic-data-types/
0005-higher-order-functions/
0006-functional-setters/
0007-setters-and-key-paths/
0008-getters-and-key-paths/
0009-algebraic-data-types-pt-2/
0010-a-tale-of-two-flat-maps/

That index is the whole interface. There is no package manifest, no library product and no version, which is consistent with the project metadata, where the primary language is Swift, the licence is MIT, the default branch is `main`, and the recent releases list says there are no GitHub releases. The last push was on 2026-10-15 and the repository is not archived.

The consequence is that the unit of consumption is a directory and a video, not a dependency. Nothing here is versioned, nothing here is packaged, and nothing here promises to keep working with a future Swift release. The value is that each directory holds the code exactly as it was written on the day, which is the thing a written tutorial cannot give you.

One structural detail is visible in the tree: a `.gitmodules` file, and some episodes that are linked rather than vendored. So the archive is not entirely self-contained, and a sample that does not open may be a submodule you have not fetched rather than a missing file.

The early arc: functions, setters and key paths

The first twenty or so episodes form a coherent curriculum on their own, and it is worth reading the titles as a syllabus.

The sequence starts with functions and side effects, moves into UIKit styling with functions, then into algebraic data types, higher-order functions, and composition without operators. From there the library work begins: functional setters, then setters and key paths, then getters and key paths, with a second algebraic data types episode on exponents and a third on generics and recursion, and a `Tagged` episode in between.

Then the episodes that show a lot of Swift developers what a functional toolkit looks like in practice. `A Tale of Two Flat-Maps` and `The Many Faces of Map` treat familiar operations as lenses onto different underlying structures, and `Contravariance` and `NonEmpty` are the two that most often change how people write generic Swift.

The dependency injection episodes sit at the end of that early run, `Dependency Injection Made Easy` and `Dependency Injection Made Comfortable`, followed by `Styling with Overture`. Together they cover the environment pattern and the use of function types to model dependencies, which is where the later architecture work gets its foundation.

`Playground Driven Development` and `A Tour of Point-Free` are the two outliers in that stretch, and both are about practice rather than a technique. The first is about using a playground as a laboratory, and the second is a tour of the toolset the team had built up to that point.

The observable pattern is that each episode directory tends to be small and self-contained, and the same vocabulary keeps returning. A setter, a getter, a key path, a reducer, an effect. Seeing the same handful of ideas rebuilt across twenty episodes is arguably more instructive than any single episode, and it is something the archive makes possible in a way that a video series does not.

The parsing arc, from combinators to a DSL

Episodes 0056 through 0064 are a self-contained course on parsing, and the titles show the shape of it.

`What Is a Parser?` runs to three parts, then `Composable Parsing` covers map, flat-map and zip, then `Parser Combinators` runs to three more parts. The order matters, and it is the order a functional programmer would recognise: first what a parser is, then the three operations you can build with, then the combinator vocabulary on top.

`Composition without Operators` earlier in the list is the conceptual companion, and `A Tale of Two Flat-Maps` is the piece that shows why flat-map is the operation that matters, since a parser that consumes input is a function that returns a parser and an output, which is exactly the shape that needs flat-map rather than map.

The DSL episodes come earlier and connect to the parsing work. `Domain Specific Languages` in two parts, then `An HTML DSL`, then `DSLs vs. Templating Languages`, which is the episode where the argument against string templates is made in code rather than in prose.

Together with `Swift Syntax Command Line Tool`, the Structs and Enums episode, and the four-part run on enum properties from 0052 to 0054, this is a large block of the archive devoted to modelling problems as Swift types rather than as data plus procedures. The `Enum Properties` run in particular, from the basic case through Swift syntax and then advanced Swift syntax, is a sequence where each episode depends on the one before it.

For a reader coming to this cold, the parsing block is the most self-contained and the most immediately useful, because a parser combinator library is a thing you can pick up and use without buying into the rest of the architecture. The state management blocks assume a much larger context.

The state management arc, which is the bulk of the archive

From episode 0065 onwards the repository becomes a body of work on application architecture, and the episode titles are the clearest summary of that method available anywhere.

`SwiftUI and State Management` runs to three parts, then `Composable State Management` covers reducers, state pullbacks, action pullbacks and higher-order reducers, then `Modular State Management` covers reducers, view state, view actions and closes with an episode literally titled The Point. `Effectful State Management` follows with synchronous effects, unidirectional effects, asynchronous effects and another The Point.

Then the testability argument, which is the real payoff of the whole arc: `Testable State Management` covers reducers, effects, ergonomics and The Point, and `SwiftUI Snapshot Testing` follows as a single episode. The pattern of naming a series after a concept and ending it with The Point is the structure: each block states a problem, and the final episode of the block says what the design is actually for.

`Composable Randomness`, `Decodable Randomness` in two parts, `Predictable Randomness` in two parts, and `Generative Art` in two parts form a separate thread on making randomness reproducible and testable, which is a problem that only shows up once state is modelled explicitly.

`The Many Faces of Flat-Map` occupies five consecutive episodes, 0042 to 0046, and `The Many Faces of Zip` three, 0023 to 0025. Those eight episodes are the archive's longest single thread, and they are the clearest example of the format's value: the same operator is examined from several angles, and each episode is small enough to read in one sitting.

The state management material, taken together, is a course in building an application whose logic is a value rather than a sequence of events, which is why the reducers, the effects and the testing episodes sit next to each other rather than being separate topics.

Case paths, modular dependency injection, and the newer work

The final stretch of the index shows the method applied to newer problems.

`The Case for Case Paths` runs to three parts, covering an introduction, properties, and then Case Paths for Free, followed by `Composing Architecture with Case Paths`. That is the thread where the earlier key path work, which was about reading and writing values, is generalised into a way of naming a case of an enum and getting a typed handle to it, which is what makes an exhaustive switch type safe.

`Dependency Injection Made Composable`, `Dependency Injection Made Modular` and `Modular Dependency Injection: The Point` return to the dependency injection theme from episodes 0016 and 0018, now with the composability and modularity vocabulary in place, so the arc closes where it started.

`Adaptive State Management` runs to four parts, covering performance, state, actions and The Point, and `Ergonomic State Management` begins a further two-part run at 0098 and 0099. Those are the newest entries in the index, and they are where the work is currently heading, with the performance episode first in the adaptive series and the ergonomics work following the composable and modular rounds.

A reader looking for the current state of the art in this style of architecture should start at 0094 and read forward, and a reader looking for the foundations should start at 0006 with setters and key paths, because almost everything later is a consequence of those two ideas.

How to read it, and what the gaps tell you

There is no install step and no usage example, because there is nothing to install. The intended interaction is: pick an episode, open the video, open the directory.

The README says the repository is the home of code written on episodes, and the index is the map. That is a subtle but important difference from a tutorial repository, because the code is not written to be read in isolation. It was written to make a point on screen, and the point often depends on a change made four minutes earlier in the same episode. A sample directory without its video can look like an odd choice of API, and reading the episode explains it.

The numbering also has a gap, and it is worth naming so it does not look like a mistake. The list runs `0040-async-functional-refactoring`, then an entry with no number, `A Tour of Snapshot Testing`, and then continues with `0042-the-many-faces-of-flatmap-pt1`. So 0041 is absent and the snapshot testing tour sits in its place without a number.

There is also the numbering to `0021-playground-driven-development` and `0022-a-tour-of-point-free`, which are not part of the algebra or setter sequence and read as interludes. The title of one, `A Tour of Point-Free`, is an inventory of the team's own libraries, which means that directory is a snapshot of what existed at that moment rather than an episode about a new idea.

The practical advice is to read the index as a map of ideas rather than a curriculum, and to pick the block that matches the problem in front of you. If you are writing a parser, read 0056 to 0064. If you are structuring a SwiftUI application, read 0065 onwards. If you want the vocabulary, read 0006 to 0008 and 0014.

Where this repository is the wrong thing to reach for

There are three reasons not to treat this as a dependency, and one reason not to treat it as a reference.

The first is that nothing is packaged. There is no version, no semantic versioning, no release, and the Swift toolchain moves. Code from episode 0044 was written against a Swift of that era, and pulling it into a project today is a porting exercise, not an import.

The second is that the samples are demonstrations, not components. A reducer shown on screen to make a point about composition is written to be read, with names chosen to fit the narration, and the type signatures are often broader than a real application needs. It is teaching code, and using it as production code means rewriting it anyway.

The third is the size. There are close to a hundred directories, and the later ones assume a lot of prior context. A team that adopts the state management architecture by copying directories out of this archive is committing to a way of structuring an application that was arrived at over dozens of episodes, and the reasoning behind the choices is spread across those episodes rather than in one file.

And the reason not to use it as a reference is the one the README itself implies. The code is a by-product of a conversation with the audience, and the most valuable part of it, the reasoning, is in the video. The archive is the transcript, not the lecture.

The alternative approach, and the one to weigh it against, is the library ecosystem the same team publishes, which is where the ideas live once they have been generalised and given a version. The distinction is the useful one: the episode code shows how an idea was reached, the library shows where it ended up. A reader who wants the destination should use the library, and a reader who wants to understand the route should come here, with the video running.

Editorial conclusion

Adopt this repository as a reading corpus if you are learning functional Swift or studying how a small team composes reducers, effects and case paths into an application architecture, since the samples are the actual code from the episodes and are grouped by topic across nearly a hundred directories. Do not adopt it as a dependency, since nothing here is packaged for consumption, and do not expect the episodes to be a linear tutorial, because the topics arrive in the order they were filmed rather than in a teaching order. Verify three things first: that the episode you want is in the directory list rather than in a linked video, that a given directory builds against a current Swift toolchain, since these are snapshots of a particular moment rather than maintained libraries, and that the numbering gaps are understood, because the list jumps from 0040 to an unnumbered snapshot testing episode and then to 0042.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pointfreeco/episode-code-samples on GitHub
4. Project website
5. README