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 Programing Made Me A Better Developer - Music City Code 2017

83 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 Programing Made Me A Better Developer - Music City Code 2017

  1. 1. How Functional Programming Made Me A Better Developer Cameron Presley @PCameronPresley http://blog.TheSoftwareMentor.com
  2. 2. About Me
  3. 3. Outline  The Journey of Learning Functional Programming  How My Style Has Evolved  How I Think About Software  Resources
  4. 4. The Journey Link
  5. 5. Some SOLID Inspiration  Mnemonic for software design coined by Robert C. Martin  By following SOLID, we tend to write more maintainable code  Want to focus on the Single Responsibility Principle
  6. 6. Some SOLID Inspiration “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
  7. 7. Some SOLID Interpretation What happens if you follow Single Responsibility to the extreme? Lots of small classes with a single method Felt like a lot of ceremony
  8. 8. Asking the Twitterverse
  9. 9. Twitter Responds!
  10. 10. Seems Like I Wasn’t The First With This Idea… http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
  11. 11. Mark’s Thoughts  Extreme SRP and ISP, leads to a lot of fine grain classes  An object can be thought of data with behavior  What if we flipped that concept around? Behavior with data  Sounds like a functional approach to the problem
  12. 12. Time to Learn Functional  Chose F#  Familiar with .NET  Comfortable with the tooling  Community resources
  13. 13. Steps Along The Journey Link
  14. 14. First Attempt
  15. 15. Premise Decided to port a C# application (Task Snapper) Grabs a screenshot every so often Focus on the language, not the problem Dipping my toes into FP
  16. 16. Implementation
  17. 17. Reflection  It’s F#!  Wrote object-oriented in a functional language  Didn’t really see the point  Need to learn more about functional
  18. 18. Second Attempt
  19. 19. Premise  Found out that card games tend to be a great exercise  Want to use Love Letter as an example card game 8 different kinds of cards, each with their own special rules  Write more idiomatic functional No classes, no exceptions
  20. 20. Implementation
  21. 21. Reflection  No exceptions!  Learning more about data modeling Making illegal state unrepresentable  Game rules a bit more complicated than expected Spending a lot of time learning the problem, not solving the problem
  22. 22. Third Attempt
  23. 23. Premise  Modeling a card game still makes sense  Something with easier business rules Able to solve a real problem without getting lost  Decided on Blackjack Just enough business rules to do something
  24. 24. Making Illegal States Unrepresentable
  25. 25. Business Rules for How Many Points a Card Is Worth
  26. 26. Business Rules For Adding Points Together
  27. 27. Calculating How Many Points For A Hand
  28. 28. Reflection  Comfortable with handling errors without exceptions  Using pattern matching more effectively  Working with built-in List operators Map and Reduce  Starting to think about how to use these concepts in C#
  29. 29. At the End  Worked on/off over the course of the year  Got frustrated at times  Spent time learning, asking questions on Twitter, StackOverflow  Didn’t give up  Starting to think about these concepts in OOP
  30. 30. Evolution of Style Link
  31. 31. Writing Testable Code
  32. 32. Why Write Testable Code? If code is easy to test, it’s usually easy to maintain Implies that hard to test code may not be maintainable What defines easy to test code?
  33. 33. A Hypothetical Which method would be easier to test? A) A method that when given the same two inputs, it returns the same output B) A method that when given the same two inputs, it returns different outputs Which method would be easier to troubleshoot?
  34. 34. Thinking About Testability Methods that always return output solely based on input are known to be pure Implies there are no side effects Interacting with a database, file system, APIs, etc.
  35. 35. Thinking About Testability  Pure methods are the easiest methods to test No mocking No fake implementations  Concept is already in use React with Redux uses this concept for its reducers Elm architecture
  36. 36. Improved LINQ
  37. 37. Typical Approach  When working with a list of data, I’d typically work with a for each loop.
  38. 38. A Different Approach  In functional programming, typically work with multiples of data as lists  Use built-in list functions to manipulate the data (map, filter)
  39. 39. Leveraging LINQ  Instead of Map and Filter, LINQ uses Select and Where
  40. 40. Useful Interfaces
  41. 41. How I Used Interfaces
  42. 42. What Is an Interface  It’s a guarantee that a method with that signature exists  Essentially a contract  If the contract is not fulfilled, the compiler tells you  Allows us to “lean” on the compiler to find errors
  43. 43. Pop Quiz! Given this interface, what should GetById return? Anything that implements this interface will always return a Record object, right?
  44. 44. How about this implementation?
  45. 45. Interfaces That Don’t Lie  Interface says that a Record will always be returned  If I handle the Record, then the compiler is happy  However, the compiler can’t enforce that I handled the null condition  Likely for me to introduce bugs into the system
  46. 46. The Functional Approach  No concept of null, use Option  Has two values, either Some<‘a> or None
  47. 47. The Functional Approach  If a function returns an Option, callers must deal with it.  Otherwise, code fails to compile
  48. 48. How My Style Evolved  Using purity to make business rules testable  Reducing complexity by leveraging LINQ  Think more about types and interfaces
  49. 49. How I Think About Software
  50. 50. Types of Components  Boundary How data comes in or goes out of the system  Business Rule How to work with data for our business needs  Workflows Combines both boundary and business rule components
  51. 51. Boundary Components  Anything that deals with getting data in/out of a system is a boundary  Examples include databases, servers, file system, user input, etc.  Makes sense to have these components implement an interface for testability  Inspired by Hexagonal Architecture by Alistair Cockburn
  52. 52. Getting Data In
  53. 53. Getting Data Out
  54. 54. Business Rule Components  Contain the rules for our application  Will make up the bulk of your application  Remember SOLID principles while implementing  For testability, purity is key
  55. 55. Business Rules
  56. 56. Workflow Components  Combines both Boundary and Business Rule components  Can be described as Data comes in through the boundary Data is processed by the business rules Data goes out through the boundary
  57. 57. Bringing It All Together
  58. 58. Bringing It All Together
  59. 59. Bringing It All Together
  60. 60. Bringing It All Together
  61. 61. Wrapping Up  Learning functional was hard for me Lots of failures, but improved incrementally  Made me re-evaluate how I build software  Still use functional concepts in my coding Even if I’m not using a functional language
  62. 62. Resources  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  Mark Seemann’s blog: (http://blog.ploeh.dk)  Hexagonal Architecture (post) by Alistair Cockburn
  63. 63. Contact Information  Cameron@TheSoftwareMentor.com  @PCameronPresley  http://blog.thesoftwarementor.com

×