After 10 years of Object Orientated Java, 2 years of Functional Programming in Scala was enough to convince me that I could never switch back. But why? The answer is simple: Functional Scala lets you think less. It reduces the number of moving parts you need to hold in your head, lets you stay focussed and saves your mental stack from overflowing. In this talk I'll show you how to stop treating Scala as a better Java and start exploring the world of Functional Programming. I'll use code examples to demonstrate a four step path that'll let you ease yourself into the world of Functional Programming while continuing to deliver production quality code. With each step we'll learn a new technique, and understand how it leaves you with less to think about: Hopefully this talk will convince you that Functional Scala leads to code that's easier to hold in your head, and leave you excited about learning a new paradigm.

7. Agenda
• Thinking less with Functions
• Thinking less with Data
• Thinking less with Patterns
• Summary
• Questions

8. Function Signatures

10. Visualizing
def f(i: Int): String = ???

11. Types and values
def f(i: Int): String = ???

12. Function
def f(i: Int): String = ???

13. Visualizing the function signature
def divide(a: Int, b: Int): Int = {
if(b == 0)
throw new ArithmeticException("/ by zero")
a / b
}

15. Feed it 0
divide(2, 0)

16. Bad function!
scala> divide(2, 0)
java.lang.ArithmeticException: / by zero
at .divide(<console>:14)
... 54 elided

17. Bad function
signature!
def divide(a: Int, b: Int): Int = {
if(b == 0)
throw new ArithmeticException("/ by zero")
a / b
}

18. Total Function
def inc(x: Int): Int = x+1

19. Pure Function
def inc(x: Int): Int = {
println("a")
x+1
}

20. Convert divide to a total function
case class DivisionError(e: String)
def divide(a: Int, b: Int): Either[DivisionError, Int] = {
if( b == 0) Left(DivisionError("/ by zero"))
Right(a / b)
}

21. Container[_] types

22. Option[_]: Returning no value is
possible
def getMiddleName(name: String):
Option[String] = ???

23. Either[_,_]: Possibility of errors
def divide(a: Int, b: Int):
Either[String, Int] = ???

24. List[_]: Multiple outputs
def getHosts(mongoUri: String):
List[String] = ???

25. Future[_]: When?
def loadUser(id: String):
Future[String] = ???

26. Recap: Function signatures
• Total functions have a corresponding
output value to each input value
• Pure functions have no side effects
• Enrich your signature with Container
types

27. Good function signatures:
Think less
About implementation

28. Parametric
Functions

30. Let's play a game!
How many implementations does
this function have?
def foo[A](a: A): A = ???

31. How many implementations does
this function have?
def foo[A](a: A): A = a

32. How many implementations does
this function have?
def foo[A](as: List[A]): List[A] = ???

33. How many implementation does
this function have?
def foo[A](as: List[A]): List[A] = {
if(as.isEmpty) Nil
else as.head :: Nil
}
def foo[A](as: List[A]): List[A] = {
if(as.isEmpty) Nil
else as.tail.toList.head :: Nil
}

34. How many implementation does
this function have?
def foo[A](a: A): Int = ???

35. How many implementation does
this function have?
def foo[A](a: A): Int = 1
def foo[A](a: A): Int = 2
def foo[A](a: A): Int = 3
def foo[A](a: A): Int = 4

36. Recap: parametric
functions
• Increase abstraction,
Lower implementation
space
• This notion is called
parametricity

37. Parametricity:
Think less
About your implementation

38. Beyond Functions

39. What about real design?
• Design data
• Design behavior

40. Encoding data using
Sum Types

41. Encoding data using Sum Types
sealed trait Developer
case class DevOps(name: String) extends Developer
case class FullStack(name: String, salary: Int) extends Developer
case class ML(name: String, salary: Long) extends Developer

42. Exhaustiveness Checking on ADTs
scala> def sayHi(d: Developer) = d match {
|
| case DevOps(n) => s"Hi $n !"
|
| case FullStack(n, _) => s"Hi $n !"
|
| }
<console>:17: warning: match may not be exhaustive.
It would fail on the following input: ML(_, _)
def sayHi(d: Developer) = d match {
^
sayHi: (d: Developer)String

43. String email or id?
case class User(
id: String,
email: String,
created: Long
)
def loadUser(user: String): User = ???

44. Encode your domain with Value
classes
case class Id(id: String) extends AnyVal
case class Email(email: String) extends AnyVal
case class TimeStamp(ts: Long) extends AnyVal
case class User(id: Id, email: Email, created: TimeStamp)
def loadUser(user: Email): User = ???

45. Recap: ADTs / Value classes
• ADTs encode immutable data
• Value classes let you add domain
knowledge

46. ADTs/Value classes:
Think less
About Correctness

47. Patterns

49. Fit this in your mental
stack!

50. Patterns at the function level
1 + 1
"a".concat("b")
List(1,2,3) ++ List(4,5,6)

53. Refactoring to a common shape
def combineInts(x: Int, y: Int): Int = ???
def combineString(x: String, y: String): String = ???
def combineLists[A](x: List[A], y: List[A]): List[A] = ???

55. Extracting to typeclasses
trait Combinable[A] {
def combine(x: A, y: A): A
}

56. You can implement
instances

57. Combinable[Int]
implicit val combineInts =
new Combinable[Int] {
def combine(x: Int, y: Int): Int =
x + y
}

58. Combinable[String]
implicit val combineStrings =
new Combinable[String] {
def combine(x: String, y: String): String =
x + y
}

59. Combinable[Foo]
case class Foo(i: Int, s: String)
implicit val combineFoos =
new Combinable[Foo] {
def combine(x: Foo, y: Foo): Foo =
Foo(x.i + y.i , x.s.concat(y.s))
}

60. Use the instances
scala> implicitly[Combinable[String]].combine("a", "b")
res6: String = ab
scala> implicitly[Combinable[Int]].combine(1, 1)
res7: Int = 2
scala> implicitly[Combinable[Foo]].combine(Foo(1,"a"), Foo(2,"b"))
res8: Foo = Foo(3,ab)

61. Nice Refactoring!
Did we gain
anything?

62. Combinable[A]
trait Combinable[A] {
def combine(x: A, y: A): A
}

63. Monoid[A]
trait Monoid[A] {
def empty: A
def combine(x: A, y: A): A
}

64. Or you can just import
Monoid
And get free
instances!

65. import cats.Monoid
import cats.instances.all._
import cats.syntax.monoid._

66. scala> 1.combine(1)
res9: Int = 2
scala> "a".combine("b")
res10: String = ab
scala> List(1,2,3).combine(List(4,5,6))
res11: List[Int] = List(1, 2, 3, 4, 5, 6)

67. "Everything sufficiently
polymorphic and useful
already exists"
-- Rob Norris @tpolecat

68. More Free code!
import cats.derived.MkMonoid._
scala> Foo(1,"a").combine(Foo(2,"b"))
res12: Foo = Foo(3,ab)

69. combineAll is a derived function
trait Monoid[A] {
def empty: A
def combine(x: A, y: A): A
def combineAll(as: List[A]): A =
as.foldLeft(empty)(combine)
}

70. scala> Monoid[Int].combineAll(List(1,2,3))
res13: Int = 6
scala> Monoid[String].combineAll(List("a","b","c"))
res14: String = abc
scala> Monoid[Foo].combineAll(Set(Foo(1,"a"),Foo(2,"b"),Foo(3,"c")))
res15: Foo = Foo(6,abc)

71. Recap: Functional Patterns
• Functional patterns are encoded as typecalsses
• As opposed to Design patterns, functional
patterns are encoded as libraries like cats
• They come with free implementations
• Ecosystem of libraries working with these
patterns

72. One very important thing
• As opposed to frameworks, functional
patterns knowledge does not get old
• You can carry with you through your career,
regardless of languages or platforms
• Some languages even support them out of
the box λ

73. Summary
• Function Signatures with total/pure
functions and container types
• Data encoded with sealed trait/case
classes
• Patterns at the function level with
typeclasses using parametric functions

74. Questions

75. Thank You
@dsebban
Come chat about FP @ BigPanda
booth