Bottom Up vs Top Down Design in Clojure
summary
Argues that modeling the domain as Clojure data and writing small composable functions produces a working API faster than class hierarchies, demonstrates a playable Cardia implementation built with 31 functions that initialize state in 40 lines of code and a full rule set in 144 lines total, uses one atom for UI state, composes top‑level state‑transform functions, and shows the game running so the approach actually works.
AI-written summary · about
chapters (28)
- 0:00Intro
- 0:23About Me
- 2:05Pieces & Parts
- 4:14Top Down Design Process Recursive Decomposition
- 5:08Games API: Version 1
- 5:42Games API: Version 2
- 6:03More Decomposition
- 6:34Games API: Version 3
- 7:16Decompose Again
- 8:54Games API: Version 4
- 11:20For Future Reference: A Potential Top Down Cartagena Class Diagram
- 12:28Fundamental Questions Answered by Bottom Up Design
- 13:07Bottom Up Design Process Functional Composition
- 16:16Required Functions
- 16:49Generator Functions
- 17:47Player Initialization
- 18:48Board Initialization Transform sequence of symbols to the board data structure
- 19:35Game Initialization
- 22:03Types of Play Functions
- 22:31Turn Sequencing
- 23:00Queries Useful predicate functions
- 23:22Determining Available Movement
- 23:47Top Level Functions
- 29:18Observations (General)
- 30:27Observations (UI)
- 32:40Why Clojure?
- 34:01Summary: Top Down vs. Bottom Up
- 35:51Final Thoughts
related talks
01h 02mSolving Problems the Clojure Way
40mFun with Functional Programming in Clojure
28mPersistent data structures - good for UI
38mFun with Functional Programming in Clojure
39mBuilding composable abstractions
36mBack to the Future: How 80s Arcade Games Taught me Clojure
32mFunctional Programming in 40 Minutes
52mDestructuring the Enterprise