Best practices always comes as snippets of advice. Nowadays you are told to be 'functional', 'immutable', 'pure', and 'reactive'. To really understand these buzzwords you need to go back to basics. In this talk, we will strip back these terms to the fundamentals. By understanding what they solve and how they solve it you will be able to make a much more informed choice over which rules to apply to your software and when it is OK to break them. By the end of this talk, you will have discovered best-practices in a more refined light, and leave writing better code than before.

1. Back to basics
aka When to break the rules
–Douglas Bader
“Rules are for the guidance of wise men and the
obedience of fools..”

2. –The Dalai Lama
“Know the rules well, so you can break them
effectively.”

3. Why do we write software?
• To solve interesting problems

4. CPU Growth
• TMS 1000 - 1974 - 0.3 Mhz - 8000 transistors
• 32 Core AMD Epyc - 2017 - 3.2 Ghz 19,200,000,000
transistors
• 2.4 Million times more transistors - 1000x faster speed

5. The complexity Crisis
• Software is limited by the our ability to reason about it.
https://img.purch.com/w/660/
aHR0cDovL3d3dy5saXZlc2NpZW5jZS5jb20vaW1hZ2VzL2kvMDAwLzAzOS84NDcvb3JpZ2luYWwvc2h1dHRlcnN0b2NrXzEwMTAwMDcwNy5qcGc=

6. What are we optimising for
• Execution Time
• Developer Time
• Time to market

7. Abstraction
• Wires
• Punched Tape
• Machine Code
• Operating Systems / Virtual Memory
• High Level Languages
• VM Languages

8. –Donald Knuth
“The average programmer no longer has time to
manipulate the binary muck, and works instead
with hierarchies of abstraction, layers upon layers
of code…”

9. Abstraction in Libraries
• Don’t reinvent the wheel
• Libraries are amazing

10. The problem with
Abstraction

11. Functional Programming is a lie!
Procedural Programming is a lie!
Assembly Programming is a lie!

12. Assembly programming is a lie
• But is is a useful lie
• Microcode
• Operating systems
• HEARTBLEED

13. Procedural programming is
a lie
• But is is a useful lie
• Optimisers
• Superscalar
• As if serial

14. Functional programming is
a lie
• But is is a useful lie
• We live in a mutable world

15. Non-Functional
programming
• No program is truly pure
• if it was we would replace it with the answer
• We care about ‘non- functionals’
• Time
• Space
• Performance
• Observability

16. Functional programming
• Total - they are defined for every input
• Deterministic - a functional will always return the same
value for the same input
• Pure - their only effect is computing their output

17. Totality

18. Values of User
• Possible values
• A valid user
• null

19. Values of Option[String]
• Possible values
• Some(<String>)
• None
• null

20. Totality
• Null like exceptions is impure
• The JVM does not prevent you passing it from returning it

21. Determinism
• a functional will always return the same value for the
same input

22. Purity
• their only effect is computing their output based on the
input

23. Don’t use Null
• Tony Hoare - ‘My Billion Dollar mistake’
• Leaky - breaks typing
• Option[String]

24. Do use Null
• A zero allocation value
• Great for high performance code - saves Option[X]
• ZIO
• https://github.com/scalaz/scalaz-zio

25. Null advice
• Use only when absolutely necessary
• Do not expose to the user

26. Low level concurrent
primitives
• wait/notify
• volatile
• Memory barriers
• java.util.concurrent

27. Should I write my own
blocking queue?

28. Always write tests
• Tests check your code work
• Tests ensure your code continues to work

29. Don’t write tests
• If its a one time hack script (thats repeatable)
• If market discovery is more important than stability

30. Use immutable data
structures
• A no brainer
• You don’t need to worry about what others do

31. Immutability
Cons

32. Do use immutable data
structures
• Externally immutable at a minimum

33. Don’t use immutable data
structures
• Concurrent hash map
• Externally immutable is ok (but its surprisingly hard)

34. Efficiency
xkcd.com

35. Efficiency
• Only optimises if something is too slow
• 3am scripts
• Migration scrips

36. Be Reactive!
• Generally avoid blocking
• Slow
• Reduces possible parallelism

37. Block all the things
• Simplicity
• Command line apps

38. Conclusion
• Computers are powerful, you can be inefficient
• Choose what you optimise for
• Computer time
• Developer time
• Generally this is a choice between clarity and speed
• Break the rules should be an active decision
• And document when you do it

39. –Terry Pratchett, Thief of Time
“Look, that's why there's rules, understand? So that
you think before you break 'em.”
Questions?