"Simple Made Easy" - Rich Hickey (2011)
Strange Loop ConferenceYouTube ↗
Further reading 7
Why does testing a business rule need a database? →Separate who qualifies for a reminder from whether the reminder can be delivered.Do separate layers really separate concerns? →Placing code in different layers leaves the underlying concepts free to depend on each other. Trace which changes still require coordinated edits.Which choices should an API leave out? →Removing an uncertain feature reduces what clients must learn. Separating tangled concerns reduces how many choices they must consider together.Why does shared mutable state tangle a program? →One talk separates identity from its successive values. The other shows how state couples parts of a system through time. Read them together to identify what a caller must know about earlier operations.Can a later update invalidate an earlier fact? →State makes an answer depend on when you ask. Recording time with a fact lets two different answers describe different moments without contradicting each other.Where should a business rule end? →Separating independent concerns becomes concrete in a functional core: compute the decision from values, then let another layer carry out its effects.When is it time to stop coding and rethink the problem? →Look for concerns that have become intertwined. Stepping away to reconsider the problem can reveal which of those dependencies really belong together.
Caption notes
Familiar tools feel easy, but the systems they produce can still entangle concerns. Look at dependencies, state and control flow to judge simplicity.
Original passages · 6
We have to start assessing our constructs based around the artifacts,don't associate simplicity with partitioning and stratification, right?a true functional interface, same input, same output.I'll just size my thread pool to be the number of cores.start seeing interconnections between things that could be independentHaving state in your program is never simple, right?