The Best Refactoring You've Never Heard Of

We're joining with Papers We Love this month for a talk about a research result with immediate software-engineering consequences, on an unrecognized but very common architectural pattern that explains a lot of things programmers already do. Once you learn about it, you start seeing it everywhere.

Please RSVP on the Papers We Love meetup group so we can add you to the building's guest list: https://www.meetup.com/Papers-We-Love-Boston-Cambridge/events/263029508/

--------------------------------

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.