# Notes from 2011 Rich Hickey presentation
https://youtu.be/LKtk3HCgTa8

## What's in your Toolkit?

| Complexity | Simplicity |
| -------------- | ------------ |
| State, Objects | Values |
| Methods | Functions, Namespaces |
| vars | Managed refs |
| Inheritance, switch, matching | Polymorphism a la carte |
| Syntax | Data |
| Imperative loops, fold | Set functions |
| Actors | Queues |
| ORM | Declarative data manipulation |
| Conditionals | Rules |
| Consistency | Inconsistency |

## The Complexity Toolkit

| Construct | Complects |
| -------------- | ------------ |
| State | Everything that touches it |
| Objects | State, identity, value |
| Methods | Function and state, namespaces |
| Syntax | Meaning, order |
| Inheritance | Types |
| Switch/matching | Multiple who/what pairs |
| var(iable)s | Value, time |
| Imperative loops, fold | what/how |
| Actors | what/who |
| ORM | OMG |
| Conditionals | Why, rest of program |

## The Simplicity Toolkit

| Construct | Get it via ... |
| -------------- | ------------ |
| Values | final, persistent collections |
| Functions | a.k.a, stateless methods |
| Namespaces | language support |
| Data | Maps, arrays, sets, XML, JSON etc. |
| Polymorphism a la carte | Protocols, type classes |
| Managed refs | Clojure/Haskell refs |
| Set functions | Libraries |
| Queues | Libraries |
| Declarative data manipulation | SQL/LINQ/Datalog |
| Rules | Libraries, Prolog |
| Consistency | Transactions, values |

## Abstraction for Simplicity
* Abstract
* drawn away
* vs Abstraction as complexity hiding
* Who, What, When, Where, Why and How
* I don't know, I don't want to know

## What
* Operations
* Form abstractions from related sets of functions
* Small sets
* Represent with polymorphism constructs
* Specify inputs, outputs, semantics
* Use only values and other abstractions
* Don't complect with:
* How

## Who
* Entities implementing abstractions
* Build from subcomponents direct-injection style
* Pursue many subcomponents
* e.g. policy
* Don't complect with:
* component details
* other entities

## How
* Implementing logic
* Connect to abstractions and entities via polymorphism constructs
* Prefer abstractions that don't dictate how
* Declarative tools
* Don't complect with:
* anything

## When, Where
* Strenuously avoid complecting these with anything in the design
* Can seep in via directly connected objects
* Use queues

## Why
* The policy and rules of the application
* Often strewn everywhere

## Information is Simple
* Don't ruin it
* By hiding it behind a micro-language
* i.e. a class with information-specific methods
* thwarts generic data composition
* ties logic to representation du jour
* Represent data as data

## Simplicity is a Choice
* Requires vigilance, sensibilities and care
* Your sensibilities equating simplicity with ease and familiarity are wrong
* Develop sensibilities around entanglement
* Your 'reliability' tools (testing, refactoring, type systems) don't care
* and are quite peripheral to producing good software

## Simplicity Made Easy
* Choose simple constructs over complexity-generating constructs
* It's the artifacts, not the authoring
* Create abstractions with simplicity as a basis
* Simplify the problem space before you start
* Simplicity often means making more things, not fewer
* Reap the benefits!