To counter the pop-culture of programming, I’m going to be doing an on-going series where I highlight talks and papers that I’ve found worthwhile. We’ll start with Rich Hickey’s famous talk Simple vs Easy: http://www.infoq.com/presentations/Simple-Made-Easy
Rich has a knack for reducing a problem to it’s purest essence. It is a pleasure being challenged by his vision of radical simplicity.
- Simple is an objective notion: we can determine whether it is entangled with something else
- Easy seduces us with familiarity: whether it’s easy to obtain (gem install), close to our capabilities, or familiar. It is a relative notion.
- We focus too much on the experience constructing it rather than the long-term implications it has.
- Familiarity (part of easy) makes programmers interchangeable
- TDD is “guard-rail-oriented programming”, Hickey emphasizes reasoning about the program itself.
- When evaluating program constructs, what matters to us is the complexity that emerges from their use. Despite some constructs being easy, they may create more complexity that is purely incidental to the problem.
- Simplicity yields ease of understanding, change, debugging.
- Composing simple components is the key to robust software.
- Separating modules doesn’t imply simplicity, nor does code organization.
- State complects value and time. It entangles everything that it touches (directly or indirectly). It cannot be contained by modules or encapsulation.
- State cannot be made simple, even when it is explicit as in Clojure or Haskell.
- “You can’t even begin to talk about how complicated an ORM is”
- Represent data as data rather than wrapping it up in objects
- Simplicity is a choice, we live in a culture of complexity
- Easy is not simple. You must develop sensibilities about entanglement.