The Next Step is Functional

Talk

Transcript

1. Anil Wadghule

   @anildigital
   λ
   The Next Step is Functional
   February, 2015
   

   View Slide

2. • Object oriented developer for 7+ years

   • In the transformation to Functional Programming world

   • Loves to solve problems with clean & simple solutions

   • Always looks to solve core problem not symptoms

   • ♥ traveling & listening music
   About me
   

   View Slide

3. • Walkthrough of SOLID design principles

   • SOLID to Functional Transformation

   • Why Functional Programming matters

   • SOLID vs FP comparison

   • Functional Principles for the object oriented developer

   • Where are we heading?
   Structure
   

   View Slide

4. Change is only CONSTANT
   Your application will change
   

   View Slide

5. • Rigid - Difficult to change
   • Fragile - Easily breakable
   • Immobile - Reuse is impossible
   • Viscous - Toughness in preserving design
   Smells of bad design
   

   View Slide

6. SOLID principles
   https://www.flickr.com/photos/fdecomite/2710132377
   

   View Slide

7. • Basic Object Oriented Programming principles

   • Makes programs easier to maintain & extend over time

   • Guidelines to remove code smells
   SOLID principles
   

   View Slide

8. Single Responsibility
   Open Closed
   Liskov’s Substitution
   Interface Segregation
   Dependency Inversion
   

   View Slide

9. Single Responsibility
   • Each class or method should have single responsibility
   • There should be never more than one reason for a class
   to change
   • The responsibility should be encapsulated
   • Separation of concerns
   

   View Slide

10. • Software entities (classes, modules, methods) should
    be open for extension, but closed for modification
    Open Closed Principle
    

    View Slide

11. • Subtypes must be substitutable for their base types
    Liskov’s Substitution
    

    View Slide

12. • Many client specific interfaces are better than
    one general purpose interface

    • Clients should not be forced on methods that
    they do not use
    Interface Segregation
    

    View Slide

13. • Depend on abstractions. Do not depend on concretions
    Dependency Inversion
    

    View Slide

14. Programming paradigms
    Imperative
    Procedural
    Object Oriented
    Functional
    Aspect Oriented
    Logic
    ?
    ? ?
    ? Symbolic
    

    View Slide

15. If you take the SOLID principles to their
    extremes, you arrive at something that makes
    Functional Programming look quite
    attractive.
    

    View Slide

16. If you take the SOLID principles to their
    extremes, you arrive at something that makes
    Functional Programming look quite
    attractive.
    https://www.flickr.com/photos/kiedyszko/15310777905
    

    View Slide

17. Objects are merely a poor mans’ closures.
    

    View Slide

18. A parable
    http://www.clipartpal.com/_thumbs/005/001/Business_Occupations/Religious/Monks/religion_buddhism_92898_tns.png
    

    View Slide

19. The venerable master Qc Na was walking with his
    student, Anton. 

    

    Hoping to prompt the master into a discussion,
    Anton said "Master, I have heard that objects are a
    very good thing - is this true?" 

    

    Qc Na looked pityingly at his student and replied,
    "Foolish pupil - objects are merely a poor man's
    closures."
    http://www.clipartpal.com/_thumbs/005/001/Business_Occupations/Religious/Monks/religion_buddhism_92898_tns.png
    

    View Slide

20. Chastised, Anton took his leave from his master and
    returned to his cell, intent on studying closures. 

    

    He carefully read the entire "Lambda: The
    Ultimate..." series of papers and its cousins, and
    implemented a small Scheme interpreter with a
    closure-based object system. 

    

    He learned much, and looked forward to informing
    his master of his progress.
    http://www.clipartpal.com/_thumbs/005/001/Business_Occupations/Religious/Monks/religion_buddhism_92898_tns.png
    

    View Slide

21. On his next walk with Qc Na, Anton attempted to
    impress his master by saying "Master, I have
    diligently studied the matter, and now understand
    that objects are truly a poor man's closures." 

    

    Qc Na responded by hitting Anton with his stick,
    saying "When will you learn? Closures are a poor
    man's object." At that moment, Anton became
    enlightened.
    - Anton van Straaten
    http://www.clipartpal.com/_thumbs/005/001/Business_Occupations/Religious/Monks/religion_buddhism_92898_tns.png
    

    View Slide

22. Closures are poor man’s object.
    

    View Slide

23. Single Responsibility → Smaller classes
    

    View Slide

24. Interface Segregation → Favour Role Interfaces over
    Header Interface
    

    View Slide

25. Lets see an example of such extreme object oriented code
    

    View Slide

26. http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    

    public interface IMessageQuery
    {
    string Read(int id);
    }
    

    View Slide

27. Objects as data with behaviour
    

    View Slide

28. http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    

    public class FileStore : IMessageQuery
    {
    private readonly DirectoryInfo workingDirectory;
    public FileStore(DirectoryInfo workingDirectory)
    {
    this.workingDirectory = workingDirectory;
    }
    public string Read(int id)
    {
    var path = Path.Combine(
    this.workingDirectory.FullName,
    id + ".txt");
    return File.ReadAllText(path);
    }
    }

    

    View Slide

29. FileStore class is a simple example of data with behaviour
    • The behaviour is Read method
    • The data (also sometimes known as state) is
    workingDirectory
    

    View Slide

30. Functions as pure behaviour
    Closures wrap data
    

    View Slide

31. Before we see Closures, lets see Functions
    

    View Slide

32. C# Func
    

    View Slide

33. http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    

    Func read = (workingDirectory, id) =>
    {
    var path = Path.Combine(workingDirectory.FullName, id +
    ".txt");
    return File.ReadAllText(path);
    };
    

    View Slide

34. There is no data and you pass workingDirectory to it. 

    This doesn’t look like object. And is just a simple function.
    

    View Slide

35. Closures as behaviour with data
    

    View Slide

36. C# Closure
    

    View Slide

37. http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    

    var workingDirectory = new DirectoryInfo(Environment.CurrentDirectory);

    

    Func read = id =>
    {
    var path = Path.Combine(workingDirectory.FullName, id + ".txt");
    return File.ReadAllText(path);
    };
    

    View Slide

38. It’s closure, because function closes over the outer
    variable workingDirectory.
    

    Effectively, the function captures the value of the
    outer variable.
    

    View Slide

39. What does that compile to?
    

    View Slide

40. http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    

    [CompilerGenerated]
    private sealed class <>c__DisplayClass3
    {
    public DirectoryInfo workingDirectory;
    public string b__2(int id)
    {
    return File.ReadAllText(
    Path.Combine(this.workingDirectory.FullName, id + ".txt"));
    }
    }
    

    View Slide

41. Closures are behaviour with data
    Objects are data with behaviour
    whereas
    

    View Slide

42. Partial function application
    

    View Slide

43. http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    

    Func read = (workingDirectory, id) =>
    {
    var path = Path.Combine(workingDirectory.FullName, id + ".txt");
    return File.ReadAllText(path);
    };
    var wd = new DirectoryInfo(Environment.CurrentDirectory);
    Func r = id => read(wd, id); // Returns partial function
    r(42);
    r(99);

    

    View Slide

44. F# Closure
    

    View Slide

45. http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    

    let workingDirectory = DirectoryInfo(Environment.CurrentDirectory)
    let read id =
    let path = Path.Combine(workingDirectory.FullName, id.ToString() + ".txt")
    File.ReadAllText(path)

    

    View Slide

46. Pure function and partial application
    

    View Slide

47. Notice how much less ceremony is involved.
    http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    

    let read (workingDirectory : DirectoryInfo) id =
    let path = Path.Combine(workingDirectory.FullName, id.ToString() + ".txt")
    File.ReadAllText(path)
    let wd = DirectoryInfo(Environment.CurrentDirectory)
    let r = read wd

    r(42)
    

    View Slide

48. Enlightenment
    https://secure.flickr.com/photos/h-k-d/3421452549/
    

    View Slide

49. Why Functional programming?
    

    View Slide

50. Object Oriented Style
    Client Component
    operation()
    add(Component)
    remove(Component)
    getChild(int)
    Leaf Composite
    operation()
    add(Component)
    remove(Component)
    getChild(int)
    Children
    operation()
    Problem broken into Object Oriented Parts
    

    View Slide

51. Object Oriented Style
    Client Component
    operation()
    add(Component)
    remove(Component)
    getChild(int)
    operation()
    add(Component)
    remove(Component)
    getChild(int)
    Children
    Component
    show()
    Component
    show()
    Composite
    Button
    show()
    

    View Slide

52. Object Oriented Interaction
    ShowButton
    click()
    HiddenPanel
    show()
    InfoPanel
    show()
    display()
    

    View Slide

53. Object Oriented Style
    Too many objects, too many states,
    mutations and hence s
    

    View Slide

54. View Slide

55. Functional Style
    md toHTML modifyDOM
    postProcess
    Problem broken into Functional Parts
    

    View Slide

56. Functional Style
    md toHTML postProcess modifyDOM
    Functions are also composed together to form more behaviours.
    visit
    post
    addId
    genID
    composed of
    

    View Slide

57. Functional Style
    md toHTML postProcess modifyDOM
    text html decorated html
    

    View Slide

58. Functional Style
    A functional program is a machine for transforming data
    

    View Slide

59. Paper talks about how higher order functions
    and lazy evaluations contribute significantly to
    modularity
    

    View Slide

60. Why Functional programming?
    • Elegance
    • Purity
    • Avoid mistakes and easy debugging
    • Facilitates multithreaded programming / concurrency
    • Programming with values
    

    View Slide

61. • Reduces code duplication
    • Allows better reuse
    • Improves code readability
    • Eliminates ugly programming by side-effects
    • It’s easy to maintain complex systems with singly responsible
    functions
    Why Functional programming?
    

    View Slide

62. SOLID vs FP
    

    View Slide

63. SOLID vs FP
    • Single Responsibility - A function which has no
    side effect. Values in Value out
    • A function therefore is by default can only have a
    single responsibility
    

    View Slide

64. SOLID vs FP
    • Open Closed - A function can be extended using
    higher order functions. Functional composition.
    • Immutable object cannot be modified under
    creation
    • Safe to add additional behaviour
    • New pure functions can’t break existing
    functionality because it can’t change state.
    • Type classes
    

    View Slide

65. SOLID vs FP
    • Liskov’s substitution principle (design by
    contract)
    • Doesn’t make much sense in FP
    • Type classes (co-variance contra-variance) kind of
    solve this.
    

    View Slide

66. SOLID vs FP
    • Interface Segregation - What could be smaller
    interface than a function?
    • Structural subtyping (Ruby, OCaml, Go)
    • Java 8 Functional Interfaces
    • Use higher order functions instead of interfaces.
    • Type classes
    

    View Slide

67. SOLID vs FP
    • Dependency Inversion - What easier to invert a
    dependency than higher order function
    • Higher order functions provide inversion of control
    • Passing typed parameters, rather than hardcoding a
    function to get value
    

    View Slide

68. SOLID vs FP
    http://www.slideshare.net/ScottWlaschin/fp-patterns-buildstufflt
    

    View Slide

69. SOLID vs FP
    So what it boils down to.
    • Just use functions and higher order functions
    • SOLID Principles followed by default in FP
    

    View Slide

70. Function Properties
    • Functions are deterministic
    • You always get same result for same inputs
    • Functions are encapsulated
    • Interface / function name tells you about behaviour
    • Functions are commutative
    • Order doesn’t matter
    • Data is immutable
    • You have to create another copy to change object
    

    View Slide

71. Patterns invisible in FP
    • Peter Norvig discussed how most of the GoF
    patterns are invisible or simpler in LISP

    http://www.norvig.com/design-patterns/
    • Norvig says patterns “programming language
    bug reports”
    • Why OO Sucks by Joe Armstrong (Some
    bashing)
    

    View Slide

72. Patterns invisible in FP
    

    View Slide

73. Patterns invisible in FP
    

    View Slide

74. Functional Principles for an 

    Object Oriented Programmer
    

    View Slide

75. Functional Principles
    • Data in, data out
    • Declarative style
    • Immutability
    • Prefer verbs instead of nouns
    • Strong typing (if possible in your lang)
    • No nulls (use libraries to use ‘Option’ like)
    • Lazy evaluation
    • Composition
    

    View Slide

76. Data in, data out
    • Only purpose should be data in and data out. Should not do
    anything else.
    • Easily tastable
    

    View Slide

77. 

    def add(a: Int, b: Int): Int = {
    return a + b
    }

    add(31, 11)
    It can be as simple like that
    

    View Slide

78. Declarative Style
    • Say what are you doing, instead of how you are doing it.
    • Many small functions
    • E.g. one line collection processing with map, filter etc
    

    View Slide

79. 

    def printArgs(args: Array[String]): Unit = {
    var i = 0
    while (i < args.length) {
    println(args(i))
    i += 1
    }
    }
    

    View Slide

80. 

    def printArgs(args: Array[String]): Unit = {
    for (arg <- args)
    println(arg)
    }
    

    View Slide

81. Declarative Style
    

    def printArgs(args: Array[String]): Unit = {
    args.foreach(println)
    }
    

    View Slide

82. Declarative Style
    

    def formatArgs(args: Array[String]) = args.mkString("\n")
    

    View Slide

83. Immutability
    • The value of an identifier never changes.
    • Objects never change.
    

    View Slide

84. Immutability
    • Like Strings in Java or C#
    • ‘Effective Java’ & ‘Effective C#’ have sections on how to do it.
    

    View Slide

85. Immutability
    • Concurrency
    • Parallelism
    

    View Slide

86. Immutability
    In functional languages

    • Pure: Everything is immutable
    • Hybrid: Immutable by default
    

    View Slide

87. Prefer verbs to nouns
    In FP langs, functions are values. They can be passed just like
    data.
    

    View Slide

88. Strong typing
    Goal is to find errors at compile time.

    

    type FirstName = String // type alias in Scala

    User(name: FirstName, email: EmailAddress)

    case class Customer(name: FirstName)

    

    View Slide

89. No nulls
    Use Optional in Java 8 or using Guava
    

    View Slide

90. Lazy Evaluation
    Delay evaluation of an expression until the last responsible moment
    

    View Slide

91. Composition
    • Objects don’t compose easily
    • Objects that represent data structures with little behaviour usually do
    compose

    • Functions can be easily composed.
    • FP composition is mathematical notion of function composition

    f(g(x))
    

    View Slide

92. val input = "Live as if you were to die
    tomorrow Learn as if you were to live
    forever"
    val grammerMap = Map("as" -> "adverb",
    "live" -> "verb",
    "if" -> "conjunction",
    "you" -> "pronoun",
    "were" -> "verb",
    "to" -> "preposition",
    "die" -> "verb",
    "tomorrow" -> "noun",
    "learn" -> "verb",
    "forever" -> "adverb")
    val highlight = (s: String) => {
    s.toUpperCase()
    }
    val grammarify = (word: String) => {
    val code = grammerMap(word.toLowerCase())
    "<" + code + ">" + word + "<" + code + "/>"
    }
    val fComposeG = grammarify.compose(highlight)
    val partOfSpeechDetector = (str: String) => {
    str.split(" ").map(fComposeG).mkString(" ")
    }
    partOfSpeechDetector(input)

    LIVE AS IF YOU
    WERE TO DIE TOMORROW
    LEARN AS IF YOU
    WERE TO LIVE FOREVER
    

    View Slide

93. 80s, 90s, Now
    

    View Slide

94. 80s
    • Multi paradigm languages
    • Smalltalk 80 had lambda expressions
    • Common Lisp Object System
    • Polyglot programmers
    • Fertile language research
    • Implementation Progress - GC, JITs, etc.
    

    View Slide

95. 90s and 2000s
    • 90s ruined everything
    • Huge Java popularity ramp
    • Servlets, J2EE then Spring
    • Virtual death of Smalltalk, LISP then Perl
    • Object Oriented Dominance
    

    View Slide

96. Now
    • Increasingly multi paradigms languages are now dominating
    • Established languages are going multi paradigm
    • Java 8 - Generics + Lambdas
    • C++ Templates
    • Newer Languages are multi paradigm
    • F#, OCaml
    • Ruby / Python / Groovy
    • New JVM languages - Scala, Ceylon, Kotlin
    

    View Slide

97. Go Functional
    • Write declarative code
    • Focus on what and not how
    • Avoid mutations, prefer immutability
    • Write more functions
    • Use functional composition
    λ
    

    View Slide

98. Thank you
    @anildigital
    λ
    

    View Slide

99. References
    • http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
    • http://blog.ploeh.dk/2012/05/25/Designpatternsacrossparadigms/
    • Functional JavaScript - Michael Fogus
    • http://www.infoq.com/news/2014/03/oo-functional-programming
    • https://skillsmatter.com/skillscasts/5156-twins-fp-and-oop-1
    • http://worrydream.com/refs/Hughes-WhyFunctionalProgrammingMatters.pdf
    • http://xahlee.info/comp/oop.html
    • http://gorodinski.com/blog/2013/09/18/oop-patterns-from-a-functional-perspective/
    • http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
    • http://www.defmacro.org/ramblings/fp.html
    • http://zeroturnaround.com/rebellabs/why-the-debate-on-object-oriented-vs-functional-programming-
    is-all-about-composition/
    • Getting started Developing with Scala - Kelsey Gilmore - Innis & Jason Swartz
    

    View Slide