Clojure slides


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Clojure slides

  1. 1. preserve order amid change, and to preserve change amid order.”- Alfred North Whitehead- Alfred North Whitehead- Alfred North Whitehead
  2. 2. Lets start right off with something really controversial....• Languages vary in power•
  3. 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. 4. Language choice matters• Less powerful langs are obviously less powerful• More powerful langs just look funny•
  5. 5. Design Patterns•• 16 of 23 GoF simply vanish in a dynamic language
  6. 6. Less is More, or Size is the Enemy• "The worst thing that can happen to a code base is size."••••
  7. 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
  8. 8. • lkl
  9. 9. Immutability“Immutable objects are simple. An immutableobject can be in exactly one state, the state inwhich it was created.... Mutable objects, on theother hand, can have arbitrarily complex statespaces.”
  10. 10. Immutability“Immutable objects are inherently thread-safe; theyrequire no synchronization.They cannot becorrupted by multiple threads accessing themconcurrently. This is far and away the easiestapproach to achieving thread safety. In fact,nothread can ever observe any effect of anotherthread on an immutable object.Therefore,immutable objects can be shared freely.”
  11. 11. Immutability“Not only can you share immutable objects, but youcan share their internals.”“Immutable objects make great building blocks forother objects.”
  12. 12. Immutability“The only real disadvantage of immutable classes isthat they require a separate object for each distinctvalue. Creating these objects can be costly,especially if they are large.”“Classes should be immutable unless there’sa very good reason to make them mutable.”
  13. 13. ImmutabilityItem 15: Minimize mutabilityEffective Java - Joshua Bloch
  14. 14. Places• In memory or on disk• Mutable objects are abstractions of places in memory• Tables, documents, records are abstractions of places on disk
  15. 15. PLOP• Place Oriented Programming• i.e. edit/update in place• New information replaces the old
  16. 16. Why are we doing this?• Carryover from early days when memory was very limited• Small RAM, small disks
  17. 17. 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
  18. 18. Values• 42• “Hello World”• 2013-02-26
  19. 19. Values• Immutable• Semantically transparent• Shared freely• Reproduceable results• (Places must establish matching state first e.g. test fixtures)• Easy to fabricate• Language Independent
  20. 20. • 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
  21. 21. What is a fact?• From the Latin, that which is done, something that happened• Includes a time component• Facts are Values, they dont change!• Information Systems are systems of facts, maintaining and manipulating• They should be value-oriented• Process constructs are inappropriate for information
  22. 22. Place is an artifact of the hardware, no rolein an information model
  23. 23. 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.
  24. 24. "No man can cross the same river twice." -Heraclitus -Heraclitus
  25. 25. Epochal Time Model• Entities are atomic values• The future is a function of the past, it doesnt 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
  26. 26. What happens if you dont 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)
  27. 27. Pure Functions• take and return values• referentially transparent• same arguments, same result• easy to understand, change, test, compose
  28. 28. • Functions presume no time• Objects pretend theres a shared timeline• Enter concurrency -> Locks!• No facility for memory/perception• (i.e. have to copy or clone)
  29. 29. • Mutable objects that can change in place, complect identity and value• The symbolic reference is the identity, which should reference a value
  30. 30. 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)
  31. 31. Decomplection• Simplicity requires work to decomplect things• NoSQL is movement away from monolithic architectures to Unix-style systems approach• CQRS• Datomic• Lambda Architecture
  32. 32. 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