## The Simplicity Toolkit

Last post we talked about simple vs easy in the context of general error handling. Here's a more general framework for thinking about simplicity, coming from Rich Hickey's talk Simple Made Easy. All distinctions made in this post are taken straight from that talk.

We start with some etymology to set the scene. Simple: sim-plex - one fold - opposite of complex. Easy (or one interpretation thereof, in order to make the distinction simple) - ease, to lie near (gem install hairball) - opposite of hard.

Simplicity is about lack of interleaving, not about cardinality. It doesn't mean one operation or one instance, it means one-fold - one role, one task, one concept, one dimension. Simplicity is objective.

• Open question: If it is objective, how do we measure it?

In this article we take it for granted that simplicity as a concept is a) understood b) desirable. There are three tables, each corresponding to a slide in Hickey's presentation. The first is a comparison of complexity and simplicity, the second is a list of complex things and what they complect, and the third is of simple constructs and how they can be achieved.

## 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, folds       | Set functions
Actors                        | Queues
ORM                           | Declarative data manipulation
Conditionals                  | Rules
Inconsistency                 | Consistency```

## The Complexity Toolkit

```Construct               | Complects
--------------------------------------------------------------
State                   | Everything that touches
Object                  | State, identity, value
Methods                 | Functions 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                     | aka, stateless methods
Namespaces                    | language support
Data                          | maps, arrays, sets, XML, JSON
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```
Today alone I've had multiple issues with: state, syntax, variables, and conditionals. That one has problems with these constructs is almost taken for granted, but it doesn't have to be that way. As I develop my sensibilities for complexity, my goal is to become more and more familiar with the simplicity toolkit, until it eventually becomes natural and, dare I say it, easy.
3 responses
3 visitors upvoted this post.