clojure slides
DESCRIPTION
TRANSCRIPT
“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