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.
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…”
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
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?