SlideShare a Scribd company logo
preserve order amid
 change, and to preserve
   change amid order.”

- Alfred North Whitehead
- Alfred North Whitehead
- 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-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
• 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
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
• lkl
Clojure slides
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
       -Heraclitus
Clojure slides
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 slides
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)
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
Clojure slides
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

More Related Content

Similar to Clojure slides (20)

PDF
Hickey jvm summit2009
Kwanzoo Dev
 
PDF
DEF CON 27 - workshop - EIGENTOURIST - hacking with monads
Felipe Prado
 
PDF
Антон Кириллов, ZeptoLab
Diana Dymolazova
 
PDF
Excavating the knowledge of our ancestors
Uwe Friedrichsen
 
KEY
LISP: How I Learned To Stop Worrying And Love Parantheses
Dominic Graefen
 
PDF
A change in perspective
Santiago Palladino
 
PDF
Functional Programming with Immutable Data Structures
elliando dias
 
PDF
On being a professional software developer
Anton Kirillov
 
PPT
Evolving as a professional software developer
Anton Kirillov
 
PPT
Trends in Programming Technology you might want to keep an eye on af Bent Tho...
InfinIT - Innovationsnetværket for it
 
PPTX
The disaster of mutable state
kenbot
 
KEY
Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...
JAX London
 
PPTX
Not Everything is an Object - Rocksolid Tour 2013
Gary Short
 
PPTX
Oop.pptx
KalGetachew2
 
PPTX
a brief explanation on the topic of Imperative Programming Paradigm.pptx
sajit20
 
PDF
Patterns for the People
Kevlin Henney
 
PPT
Oop concept
Waseem Mehmood
 
PPTX
Solid OOPS
Toshish Jawale
 
PDF
Flow based-1994
getdownload
 
PPTX
Into the Land of lambda, One Programmer's Journey Into Functional Programming
Mike Pence
 
Hickey jvm summit2009
Kwanzoo Dev
 
DEF CON 27 - workshop - EIGENTOURIST - hacking with monads
Felipe Prado
 
Антон Кириллов, ZeptoLab
Diana Dymolazova
 
Excavating the knowledge of our ancestors
Uwe Friedrichsen
 
LISP: How I Learned To Stop Worrying And Love Parantheses
Dominic Graefen
 
A change in perspective
Santiago Palladino
 
Functional Programming with Immutable Data Structures
elliando dias
 
On being a professional software developer
Anton Kirillov
 
Evolving as a professional software developer
Anton Kirillov
 
Trends in Programming Technology you might want to keep an eye on af Bent Tho...
InfinIT - Innovationsnetværket for it
 
The disaster of mutable state
kenbot
 
Bluffers guide to elitist jargon - Martijn Verburg, Richard Warburton, James ...
JAX London
 
Not Everything is an Object - Rocksolid Tour 2013
Gary Short
 
Oop.pptx
KalGetachew2
 
a brief explanation on the topic of Imperative Programming Paradigm.pptx
sajit20
 
Patterns for the People
Kevlin Henney
 
Oop concept
Waseem Mehmood
 
Solid OOPS
Toshish Jawale
 
Flow based-1994
getdownload
 
Into the Land of lambda, One Programmer's Journey Into Functional Programming
Mike Pence
 

Clojure slides

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