“The art of progress is to preserve order amid change, and to

preserve change amid order.”

- Alfred North Whitehead

Let's start right off with something

really controversial....

•Languages vary in power

•http://www.paulgraham.com/diff.html

Any Turing complete language is just as good as another.

+++++ +++++ [ > +++++ ++ > +++++ +++++ > +++ > + <<<< - ] > ++ . > + . +++++ ++ . . +++ . > ++ . << +++++ +++++ +++++ . > . +++ . ----- - . ----- --- . > + . > .

"Beware of the Turing tarpit in which everything is possible but nothing of interest is easy." —Alan Perlis, Epigrams on Programming

Language choice matters

•Less powerful langs are obviously less powerful

•More powerful langs just look funny

• http://www.paulgraham.com/avg.html

Design Patterns

•http://norvig.com/design-patterns/

•16 of 23 GoF simply vanish in a dynamic language

Less is More, or Size is the Enemy

•"The worst thing that can happen to a code base is size."

•http://www.codinghorror.com/blog/2007/12/size-is-the-enemy.html

•http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

•http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html

•http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

•Corollary with Lean Methodology (MIT Sloan)

•Value Ratio => Value time / Cycle time

•<= 7% in most orgs!!!!

•i.e. 93% waste

•Improvement strategy needs to be substractive not additive

•Agile not about process

•"There is nothing so useless as doing something effciently that need not be done at all." - Peter Drucker

•lkl

Immutability

“Immutable objects are simple. An immutable object can be in exactly one state, the state in which it was created.... Mutable objects, on the other hand, can have arbitrarily complex state spaces.”

Immutability“Immutable objects are inherently thread-safe; they require no synchronization.They cannot be corrupted by multiple threads accessing them concurrently. This is far and away the easiest approach to achieving thread safety. In fact,no thread can ever observe any effect of another thread on an immutable object.Therefore, immutable objects can be shared freely.”

Immutability

“Not only can you share immutable objects, but you can share their internals.”

“Immutable objects make great building blocks for other objects.”

Immutability“The only real disadvantage of immutable classes is that they require a separate object for each distinct value. Creating these objects can be costly, especially if they are large.”

“Classes should be immutable unless there’s a very good reason to make them mutable.”

Immutability

Item 15: Minimize mutability

Effective Java - Joshua Bloch

Places

•In memory or on disk

•Mutable objects are abstractions of places in memory

•Tables, documents, records are abstractions of places on disk

PLOP

•Place Oriented Programming

•i.e. edit/update in place

•New information replaces the old

Why are we doing this?

•Carryover from early days when memory was very limited

•Small RAM, small disks

This is not how the real world works.

•Memory is an open, associative system, not an addressable system

•Records (e.g. bookkeeping) accrete, accumulate over time

•New does not replace old

Values

•42

•“Hello World”

•2013-02-26

Values

•Immutable

•Semantically transparent

•Shared freely

•Reproduceable results

•(Places must establish matching state first e.g. test fixtures)

•Easy to fabricate

•Language Independent

•Generic

•(Places require operational interface e.g. Person class)

•Aggregation

•Conveyance (aliasing)

•(mutable object in a queue?)

•Perception (no locking, in process or disk) (mutable object with multiple getters?)

•Memory (aliasing?) (mutable objects must be copied or cloned)

•Values make the best interface

What is a fact?

•From the Latin, that which is done, something that happened

•Includes a time component

•Facts are Values, they don't change!

•Information Systems are systems of facts, maintaining and manipulating

•They should be value-oriented

•Process constructs are inappropriate for information

Place is an artifact of the hardware,

no role in an information model

How did we make this mistake?

•Traced back to the time when a program was the extent of the known universe.

•Distributed systems and new architectures forcing a reconsideration.

"No man can cross the same river twice."

-Heraclitus

Epochal Time Model

•Entities are atomic values

•The future is a function of the past, it doesn't change it

•Process creates the future from the past

•We associate identities with a series of related values

•Time is atomic, epochal succession of events

What happens if you don't model this correctly?

•time - present is unreliable, past is nonexistent

•identity - locking + convention

•perception - locking or copy/clone

•action - side effects everywhere (where does mutation happen? everywhere)

Pure Functions

•take and return values

•referentially transparent

•same arguments, same result

•easy to understand, change, test, compose

•Functions presume no time

•Objects pretend there's a shared timeline

•Enter concurrency -> Locks!

•No facility for memory/perception

•(i.e. have to copy or clone)

•Mutable objects that can change in place, complect identity and value

•The symbolic reference is the identity, which should reference a value

Clojure•Functional

•Immutable (by default)

•Dynamically typed, dynamically compiled

•Interactive REPL

•Load/change code in the live environment

•Code as data

•Small core

•Sequences (not cons cells)

Decomplection

•Simplicity requires work to decomplect things

•NoSQL is movement away from monolithic architectures to Unix-style systems approach

•CQRS

•Datomic

•Lambda Architecture

Power vs Protection

•“Java is C++ without the guns, knives, and clubs.” - James Gosling

•Power langs push us to the ends of the Bell Curve

•Protection langs push us to the middle

•The trend is toward power langs

•“End of the Era of Paternalistic Languages” -Michael Feathers