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.

1. How Functional Programming
Made Me A Better Developer
Cameron Presley
@PCameronPresley
http://blog.TheSoftwareMentor.com

2. Thank The Sponsors!

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

5. The Journey
Link

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

9. Asking the Twitterverse

10. Twitter Responds!

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

31. Evolution of Style
Link

32. Writing Testable Code

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

42. Useful Interfaces

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