How Functional Programming Made Me A Better Developer
Download as PPTX, PDF2 likes338 views
The document discusses how learning functional programming improved the author's skills as a developer. It describes their journey learning F# by porting projects like a screenshot tool and card games. This helped them think more about pure functions, immutable data, and leveraging LINQ. It influenced how they write more testable code through interfaces and by avoiding null values. The author now considers types of components like boundaries, business rules, and workflows when building software. Overall, learning functional programming was challenging but improved their ability to design maintainable and testable systems.
How Functional Programming Made Me A Better Developer
- 1. How Functional Programming Made Me A Better Developer Cameron Presley @PCameronPresley http://blog.TheSoftwareMentor.com
- 3. Little About Me From Knoxville, TN Software Engineer at Pilot Flying J Musician, board gamer, and mentor Co-organizer of FunctionalKnox
- 4. Outline The Journey of Learning Functional Programming How My Style Has Evolved How I Think About Software Resources
- 6. Some SOLID Inspiration Mnemonic for software design coined by Robert C. Martin By following SOLID, we tend to write more maintainable code Teach and present on SOLID a lot Want to focus on the Single Responsibility Principle
- 7. 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
- 8. 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
- 11. Seems Like I Wasn’t The First With This Idea… http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
- 12. 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
- 13. Time to Learn Functional Chose F# Familiar with the .NET framework Comfortable with the .NET tooling Community resources
- 14. Steps Along The Journey Link
- 15. First Attempt
- 16. 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
- 17. Implementation
- 18. Reflection It’s F#! Wrote object-oriented in a functional language Definitely not idiomatic Didn’t really see the point Need to learn more about functional
- 19. Second Attempt
- 20. 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
- 21. Implementation
- 22. 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
- 23. Third Attempt
- 24. 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
- 25. Making Illegal States Unrepresentable
- 26. Business Rules for How Many Points a Card Is Worth
- 27. Business Rules For Adding Points Together
- 28. Calculating How Many Points For A Hand
- 29. 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#
- 30. 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
- 33. 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?
- 34. A Hypothetical Pretend we were writing tests around a particular method. Which one would you rather 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
- 35. Thinking About Testability If a method always returns output solely based on inputs, we call that method pure. No side effects or state involved Easiest types of test to write No mocking, no fake implementations to use Frameworks that use this concept Reducers (Redux) Elm architecture
- 37. Improved LINQ
- 38. Typical Approach When working with a list of data, I’d typically work with a for each loop.
- 39. A Different Approach In functional programming, typically work with multiples of data as lists Typically use built-in list functions (map, filter)
- 40. Leveraging LINQ Instead of Map and Filter, LINQ uses Select and Where
- 43. How I Used Interfaces
- 44. 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 use the compiler to find errors “Leaning on the compiler”
- 45. Pop Quiz! Given this interface, what should GetById return? Anything that implements this interface will always return a Record object, right?
- 46. How about this implementation?
- 47. 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
- 48. The Functional Approach No concept of null, typically use something called Option or Maybe Has two values, either Some<‘a> or None
- 49. The Functional Approach If a function returns an Option, callers must deal with it. Otherwise, code fails to compile
- 50. How My Style Evolved Using purity to make business rules testable Reducing complexity by leveraging LINQ Think more about types and interfaces
- 51. How I Think About Software
- 52. 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
- 53. 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
- 54. Getting Data In
- 55. Getting Data Out
- 56. 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
- 57. Business Rules
- 58. 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
- 59. Bringing It All Together
- 60. Bringing It All Together
- 61. Bringing It All Together
- 62. Bringing It All Together
- 63. 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
- 64. 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
Editor's Notes
- #15: I worked on/off with functional for a year Lots of heads down, then come up for air for a bit Rinse and repeat Took three attempts for me to really “get” it