Caio Amaral

Simple Made Easy -

“Simplicity is a prerequisite for reliability”
- Edsger W. Dikstra

Word Origins

Simple

  • Sim- plex
  • one fold/braid
  • vs complex

Simple

One fold/braid - One role - One task - Once concept - One dimention
But Not - One instance - One Operation
  • About lacking of interleaving not cardinality
  • Objective

Easy

  • ease < aise < adhacebs
  • lie near
  • vs hard

Easy

  • Near, at hand
    • on our hard drive, in our tool set, IDE, apt get, gem install
  • Near to understanding
    • Familiar
  • Near our capabilities
  • Easy is relative

Construct vs Artifact

  • We focus on experience of use of construct
    • programmer convinience
    • programmer replaceability
  • Rather than the long term results of use
    • software quality correctness
    • Maintainable, change
  • We must assess constructs by their artifacts

Limits

  • We can only hope to make reliable those things we can understand
  • We can only consider a few things at a time
  • Intertwined things must be considered together
  • Complexity undermines understanding

Change

  • Change to software require analysis and decisions
  • What will be impacted?
  • Where do changes need to be made?
  • Your ability to reason about your program is critical to changing it without fear
    • Not talking about proof, just informal reasoning

Debugging

  • What’s true of every bug found in the field?
  • it has passed the type checker
    • and all tests
  • Your ability to reason about your program is critical to debugging

Development Speed

  • Emphasizing ease gives early speed
  • Ignoring complexity will slow you down over the long haul
  • On throwaway or trivial projects, nothing much matters

Easy Yet Complex?

  • Many complicating constructs are:
    • Siccinctly described
    • Familiar
    • Available
    • Easy to use
  • What matters in the complexity thy yield
    • Any such complexity is incidental

Benefits of Simplicity

Lego castles are better than concrete ones.

  • Ease understanding
  • Ease of change
  • Easier debugging
  • Flexibility
    • Policy
    • Location (etc)

Making Things Easy

How easy things are is the distance between you and what you’re trying to achieve. Making things simple, will actually make things easier

  • Bring to hand by installing
    • getting approved for use
  • Become familiar by learning, trying
  • But mental capability
    • not going to move very far
    • make things near by simplifying them

Parens are Hard!

  • Not at hand for most
  • Nor familiar
  • But are they simple?
  • Not in CL/Scheme
    • overloaded for calls and grouping
  • Adding a data structure for grouping, e.g. vectors makes each simpler
    • overloading is complexity reduced by adding more things

“LISP programmers know the value of everything and the cost of nothing.”
- Alan Perlis

Not only benefits! We need to look for trade off’s

What’s in your toolkit?

child_database

Complect

  • To interleave, entwine, braid
  • Don’t do it!
    • Completing things is the source of complexity
  • Best to avoid in the first place

Compose

  • To place together
  • Composing simple components is the key to robust software.

Modularity and Simplicity

  • Partitioning and stratification don’t imply simplicity
    • but are enabled by it
  • Don’t be fulled by code organization

State is Never Simple

  • Complects value and time
  • It is easy, in the at-handed and familiar senses
  • Interweaves everything that touches it, directly or indirectly
    • Not mitigated by modules, encapsulation
  • Note - this has nothing to do with asynchrony

Not all refs/vars are Equal

  • None make state simple
  • All warn of state, help reduce it
  • Clojure and Haskell refs compose value and time
    • Allow you to extract a simple value
    • Provide abstractions of time
  • Does your var do that?

The Complexity Toolkit

child_database

Environmental Complexity

  • Reources, e.g. memory, CPU
  • Inherent complexity in implementation space
    • All components contend for them
  • Segmentation
    • waste
  • Individual policies don’t compose

Abstraction for Simplicity

  • Abstract
    • Drawn away
  • vs Abstraction as complexity hiding
  • I don’t know, I don’t want to know

Simplicity is not an objective in art, but one achieves simplicity despite one’s self by entering into the real sense of things.

Lists and Order

  • Sequence of thigns
  • Does order matter?
    • [first-thing second-thing third-thing …]
    • [depth width heigh]
  • set[x y z]
    • order clearly doesn’t matter

Why Care about Order?

  • Complects each thing with the next
  • Infects usage points
  • Inhibits change
  • [name email] → [name phone email]

Order in the Wild

child_database

Maps, Dammit!

  • First class associative data structures
  • Idiomatic Support
    • Literals, ancessors, symbolic keys

Information is Simple

  • Don’t ruin it
  • By hidding 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.

Encapsulation

  • Is for implementation details
  • Information doesn’t have implementation
    • Unless you added it - why?
  • Information will have representation
    • have to pick one

Can You Move it?

  • Litmus test - can you move your subsystems?
    • out of proc, different language, different thread?

Subsystems Must Have

  • Well defined boundaries
  • Abstracted operational interface (verbs)
  • General error handling
  • Taken/return data
    • IPersonInfo -oops!
    • Not just a matter of serializers

Simplicity is a Choice

  • Requires Vigilance, sinsibilities 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 if simple or not
    • and are peripheral to producing simple software.

Simplicity Made Easy

  • Choose simple constructs over complecity-generating constructs
    • It’s the artifacts, not authoring
  • Create abstractions with simplicity as a basis
  • Simplify the problem space before you start
  • Simplicity often means making more things, not fewer.

“Simplicity is the ultimate Sophistication”
- Leonardo Da Vinci