Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How Functional Programming Made Me a Better Developer

120 views

Published on

With the rise in popularity recently, functional programming has become ""The Next Big Thing"". As of today, there are tons of frameworks and tools that can be used for front-end, back-end, desktop, and mobile development. With that being said, the majority of us are still using object-oriented languages for our day jobs and don't need to learn functional programming, right?

In this talk, I'll walk you through my experiences learning functional programming over the last year, how my style of programming has changed, and how I now think about programming with regards to both functional and object-oriented paradigms.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

How Functional Programming Made Me a Better Developer

  1. 1. Cameron Presley @pcameronpresley Cameron@TheSoftwareMentor.com How Functional Programming Made Me a Better Developer
  2. 2. 2 Hello!
  3. 3. 3
  4. 4. 4
  5. 5. “ The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. -Wikipedia 5
  6. 6. “ The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. -Wikipedia 6
  7. 7. What Happens If You Follow SRP to the Extreme? 7
  8. 8. 8
  9. 9. 9
  10. 10. 10
  11. 11. 11 http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
  12. 12. Extreme SRP and ISP = lots of fine grain classes 12
  13. 13. Objects can be thought of data with behavior, but what if we flipped that around? 13
  14. 14. 14 F#
  15. 15. 15
  16. 16. 16
  17. 17. Task Snapper ○ C# application that grabs a screenshot every so often ○ Focus on the language, not the problem 17
  18. 18. 18
  19. 19. 19
  20. 20. 20
  21. 21. 21
  22. 22. 22
  23. 23. 23
  24. 24. Love Letter ○ 8 different kinds of cards, each with their own rules ○ Write more idiomatic fp ○ No classes or exceptions 24
  25. 25. 25
  26. 26. 26
  27. 27. 27
  28. 28. 28
  29. 29. 29
  30. 30. 30
  31. 31. Blackjack! ○ Still modeling a card game ○ Something with easier business rules ○ Already knew the rules 31
  32. 32. 32
  33. 33. 33 How would you score a hand in Blackjack? Figure out how many Points each Card is worth Add the Points up
  34. 34. 34
  35. 35. 35
  36. 36. 36
  37. 37. 37
  38. 38. 38
  39. 39. 39
  40. 40. 40 different outputs the same output A method, that when given the same two inputs, it returns…
  41. 41. 41 Methods that always return output solely based on input are known to be pure
  42. 42. 42 Sound crazy? Elm React with Redux
  43. 43. 43
  44. 44. 44
  45. 45. 45
  46. 46. 46
  47. 47. 47
  48. 48. 48
  49. 49. 49
  50. 50. 50
  51. 51. 51
  52. 52. 52
  53. 53. 53 Interfaces are powerful because they enforce a contract at the code level. If the contract isn’t observed, the code won’t compile!
  54. 54. Given this interface, what should GetById return? Pop Quiz! Anything that implements this interface will always return an Employee object, right?
  55. 55. 55
  56. 56. 56
  57. 57. 57 What Happened? Interface said that an Employee will always be returned But sometimes, there won’t be an Employee, so what to return? Compiler can’t enforce that I handle null / exceptions
  58. 58. 58
  59. 59. 59
  60. 60. 60
  61. 61. 61
  62. 62. 62 Boundary (data in/out) Business Rules (processing the data) Workflow (combination of both)
  63. 63. Boundary ○ Databases, files, APIs ○ Typically impure ○ For easier testing of workflows, recommend using an interface ○ Inspiration from Alistair Cockburn’s Hexagonal Architecture 63
  64. 64. 64
  65. 65. 65
  66. 66. Business Rules ○ Bulk of the application ○ Purity is key ○ Remember SOLID when implementing 66
  67. 67. 67
  68. 68. Workflows ○ Combines both Boundary and Business Rule ○ General shape is: ○ Data comes in through the boundary ○ Data is processed by the business rules ○ Data goes out through the boundary 68
  69. 69. 69
  70. 70. 70
  71. 71. 71
  72. 72. 72
  73. 73. 73
  74. 74. 74
  75. 75. 75 References F# • F Sharp for Fun and Profit (https://fsharpforfunandprofit.com) • The Book of F#: Breaking Free with Managed Functional Programming by Dave Fancher • F# Jumpstart (Pluralsight Course) by Kit Eason Functional • Mark Seemann’s blog: (http://blog.ploeh.dk) • Hexagonal Architecture (post) by Alistair Cockburn • Reid Evans YouTube (https://www.youtube.com/channel/UCMxR2KmDlDMEsvfKOjzRNbA) Code • CRUDy : https://github.com/cameronpresley/CRUDy • Optionally: https://github.com/cameronpresley/Optionally
  76. 76. Feedback! 76 http://blog.TheSoftwareMentor.com/F eedback

×