KEMBAR78
How Functional Programming Made Me A Better Developer | PPTX
How Functional Programming
Made Me A Better Developer
Cameron Presley
@PCameronPresley
http://blog.TheSoftwareMentor.com
Thank The Sponsors!
Little About Me
ī‚´ From Knoxville, TN
ī‚´ Software Engineer at Pilot Flying J
ī‚´ Musician, board gamer, and mentor
ī‚´ Co-organizer of FunctionalKnox
Outline
ī‚´ The Journey of Learning Functional Programming
ī‚´ How My Style Has Evolved
ī‚´ How I Think About Software
ī‚´ Resources
The Journey
Link
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
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
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
Asking the Twitterverse
Twitter Responds!
Seems Like I Wasn’t The First With This
Ideaâ€Ļ
http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
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
Time to Learn Functional
ī‚´ Chose F#
ī‚´ Familiar with the .NET framework
ī‚´ Comfortable with the .NET tooling
ī‚´ Community resources
Steps Along The Journey
Link
First Attempt
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
Implementation
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
Second Attempt
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
Implementation
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
Third Attempt
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
Making Illegal States Unrepresentable
Business Rules for How Many Points
a Card Is Worth
Business Rules For Adding Points Together
Calculating How Many Points For
A Hand
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#
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
Evolution of Style
Link
Writing Testable Code
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?
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
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
Improved LINQ
Typical Approach
ī‚´ When working with a list of data, I’d typically work with a for each loop.
A Different Approach
ī‚´ In functional programming, typically work with multiples of data as lists
ī‚´ Typically use built-in list functions (map, filter)
Leveraging LINQ
ī‚´ Instead of Map and Filter, LINQ uses Select and Where
Useful Interfaces
How I Used Interfaces
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”
Pop Quiz!
Given this interface, what should GetById return?
Anything that implements this interface
will always return a Record object, right?
How about this implementation?
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
The Functional Approach
ī‚´ No concept of null, typically use something called Option or Maybe
ī‚´ Has two values, either Some<‘a> or None
The Functional Approach
ī‚´ If a function returns an Option, callers must deal with it.
ī‚´ Otherwise, code fails to compile
How My Style Evolved
ī‚´ Using purity to make business rules testable
ī‚´ Reducing complexity by leveraging LINQ
ī‚´ Think more about types and interfaces
How I Think About Software
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
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
Getting Data In
Getting Data Out
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
Business Rules
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
Bringing It All Together
Bringing It All Together
Bringing It All Together
Bringing It All Together
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
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

How Functional Programming Made Me A Better Developer

  • 1.
    How Functional Programming MadeMe A Better Developer Cameron Presley @PCameronPresley http://blog.TheSoftwareMentor.com
  • 2.
  • 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 Journeyof Learning Functional Programming ī‚´ How My Style Has Evolved ī‚´ How I Think About Software ī‚´ Resources
  • 5.
  • 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 “Thesingle 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 Whathappens if you follow Single Responsibility to the extreme? Lots of small classes with a single method Felt like a lot of ceremony
  • 9.
  • 10.
  • 11.
    Seems Like IWasn’t The First With This Ideaâ€Ļ http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
  • 12.
    Mark’s Thoughts ī‚´ ExtremeSRP 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 LearnFunctional ī‚´ Chose F# ī‚´ Familiar with the .NET framework ī‚´ Comfortable with the .NET tooling ī‚´ Community resources
  • 14.
    Steps Along TheJourney Link
  • 15.
  • 16.
    Premise ī‚´ Decided toport a C# application (Task Snapper) ī‚´ Grabs a screenshot every so often ī‚´ Focus on the language, not the problem ī‚´ Dipping my toes into FP
  • 17.
  • 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.
  • 20.
    Premise ī‚´ Found outthat 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.
  • 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.
  • 24.
    Premise ī‚´ Modeling acard 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 StatesUnrepresentable
  • 26.
    Business Rules forHow Many Points a Card Is Worth
  • 27.
    Business Rules ForAdding Points Together
  • 28.
    Calculating How ManyPoints For A Hand
  • 29.
    Reflection ī‚´ Comfortable withhandling 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.
  • 32.
  • 33.
    Why Write TestableCode? ī‚´ 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 wewere 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.
  • 38.
    Typical Approach ī‚´ Whenworking 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 ī‚´ Insteadof Map and Filter, LINQ uses Select and Where
  • 42.
  • 43.
    How I UsedInterfaces
  • 44.
    What Is anInterface ī‚´ 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 thisinterface, what should GetById return? Anything that implements this interface will always return a Record object, right?
  • 46.
    How about thisimplementation?
  • 47.
    Interfaces That Don’tLie ī‚´ 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 StyleEvolved ī‚´ Using purity to make business rules testable ī‚´ Reducing complexity by leveraging LINQ ī‚´ Think more about types and interfaces
  • 51.
    How I ThinkAbout 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 ī‚´ Anythingthat 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.
  • 55.
  • 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.
  • 58.
    Workflow Components ī‚´ Combinesboth 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.
  • 60.
  • 61.
  • 62.
  • 63.
    Wrapping Up ī‚´ Learningfunctional 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 Sharpfor 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