We're excited to have James Koppel reprise his talk from this summer's Compose Conference NYC!
Doors will open at 6pm, talk will start at 6:30.
Every problem can be solved by many designs. Often the relation between two designs is that one is a transformation of another. When we understand how to mechanically transform designs, we can more easily explore the design space, and effortlessly identify the tradeoffs.
So, what do these design changes have in common?
- Letting a search procedure take an arbitrary filter function, instead of a fixed set of options
- Changing a program using blocking I/O to non-blocking I/O with an event loop
- Letting a user stop in the middle of an action — and resume it after a server reboot
Answer: They’re all instances of a transformation called “defunctionalization” or its inverse, “refunctionalization.” Come learn how it works, and learn to recognize when a proposed design change is just an instance of this general technique. In doing so, you’ll learn how the tradeoffs between designs can be boiled down into a single slogan: refunctionalized is more open, defunctionalized is more inspectable. As a plus, you’ll also learn how defunctionalization is the oldest technique to compile functional languages.