1. preserve order amid
change, and to preserve
change amid order.”
- Alfred North Whitehead
- Alfred North Whitehead
- Alfred North Whitehead

2. Let's start right off with
something really
controversial....
• Languages vary in power
• http://www.paulgraham.com/diff.html

3. 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
<< +++++ +++++ +++++ . > .
+++ . ----- - .
----- --- . >+.
>.

4. Language choice matters
• Less powerful langs are obviously less powerful
• More powerful langs just look funny
• http://www.paulgraham.com/avg.html

5. Design Patterns
• http://norvig.com/design-patterns/
• 16 of 23 GoF simply vanish in a dynamic
language

6. 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-e
• http://steve-yegge.blogspot.com/2007/12/codes-worst-e
• http://steve-yegge.blogspot.com/2008/06/rhinos-and-tige
• http://steve-yegge.blogspot.com/2006/03/execution-in-k

7. • 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

19. • lkl

21. 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.”

22. 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.”

23. Immutability
“Not only can you share immutable objects, but you
can share their internals.”
“Immutable objects make great building blocks for
other objects.”

24. 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.”

25. Immutability
Item 15: Minimize mutability
Effective Java - Joshua Bloch

26. Places
• In memory or on disk
• Mutable objects are abstractions of places
in memory
• Tables, documents, records are abstractions
of places on disk

27. PLOP
• Place Oriented Programming
• i.e. edit/update in place
• New information replaces the old

28. Why are we doing this?
• Carryover from early days when memory
was very limited
• Small RAM, small disks

29. 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

30. Values
• 42
• “Hello World”
• 2013-02-26

31. Values
• Immutable
• Semantically transparent
• Shared freely
• Reproduceable results
• (Places must establish matching state first
e.g. test fixtures)
• Easy to fabricate
• Language Independent

32. • 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

33. 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

34. Place is an artifact of
the hardware, no role
in an information model

35. 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.

36. "No man can cross the same
river twice."
-Heraclitus
-Heraclitus

38. 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

39. 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)

40. Pure Functions
• take and return values
• referentially transparent
• same arguments, same result
• easy to understand, change, test, compose

41. • 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)

42. • Mutable objects that can change in place,
complect identity and value
• The symbolic reference is the identity,
which should reference a value

44. 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)

53. Decomplection
• Simplicity requires work to decomplect things
• NoSQL is movement away from monolithic
architectures to Unix-style systems approach
• CQRS
• Datomic
• Lambda Architecture

54. 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