2 edited body
source | link

Functional programming is not about having no state. Instead, all that immutability stuff is about making state explicit. A simple example is adding a list of numbers. In Python, we would do something like this:

xs = [1, 2, 3, 4, 5]
sum = 0
for x in xs:
  sum += x

(Actually, we'd use the sum builtin, but this is just an example). This loop is stateful, because we mutate the sum variable at each iteration. The sum variable is not referentially transparent, because it points to different values at different points of time. The state is encoded in the control flow. Scala is not dogmatic about functional programming, and allows you to write code in a stateful way. However, you are encouraged to limit implicit state.

How could we make state explicit, or get rid of it when summing numbers? We can define the sum of a list as zero ofif the list is empty, and the first element plus the sum if the remaining elements otherwise. Note that this is a recursive definition. In Scala, we'd write it as

val xs = Seq(1, 2, 3, 4, 5)

def summer(xs: Seq[Int]): Int = xs match {
  case Seq() => 0
  case x :: rest => x + summer(rest)
}

val sum = summer(xs)

Note that while we have made the for … in … loop recursive, there still is no obvious state. This is because the recursive function uses the call stack to store intermediate values. The state of the loop becomes explicit if we write it as a tail-recursive function:

import scala.annotation.tailrec

@tailrec
def summer(xs: Seq[Int], acc: Int = 0): Int = xs match {
    case Seq() => acc
    case x :: rest => summer(rest, x + acc)
}

The acc (accumulator) argument represents the state here. It is not mutated, instead we create a new state for each iteration.

In fact, performing such an operation is so common that it's usually done via fold (or foldLeft, which allows the result to be of a different type):

def summer (xs: Seq[Int]): Int = (xs fold 0) (_ + _)

How does explicit state mesh with object-oriented programming? Quite well, actually: the object is the state. Think of the current object as a parameter that is invisibly being passed along in any method call. However, you never mutate the state, and instead create a new one. Careful though: this can make some data structures horribly inefficient if not designed with immutability in mind.

What does this mean for implementing a REST API? Nothing. It is your job as a programmer to decide which paradigms and patterns are suitable in any given situation. Using explicit state can have benefits, but it might also be obfuscation of what's really happening. In any case, different parts of the program can use different amounts of Functional Programming. Using FP patterns is possible even at a fairly small scale, and does not require your whole program to be written in absolute “purity”.

Functional programming is not about having no state. Instead, all that immutability stuff is about making state explicit. A simple example is adding a list of numbers. In Python, we would do something like this:

xs = [1, 2, 3, 4, 5]
sum = 0
for x in xs:
  sum += x

(Actually, we'd use the sum builtin, but this is just an example). This loop is stateful, because we mutate the sum variable at each iteration. The sum variable is not referentially transparent, because it points to different values at different points of time. The state is encoded in the control flow. Scala is not dogmatic about functional programming, and allows you to write code in a stateful way. However, you are encouraged to limit implicit state.

How could we make state explicit, or get rid of it when summing numbers? We can define the sum of a list as zero of the list is empty, and the first element plus the sum if the remaining elements otherwise. Note that this is a recursive definition. In Scala, we'd write it as

val xs = Seq(1, 2, 3, 4, 5)

def summer(xs: Seq[Int]): Int = xs match {
  case Seq() => 0
  case x :: rest => x + summer(rest)
}

val sum = summer(xs)

Note that while we have made the for … in … loop recursive, there still is no obvious state. This is because the recursive function uses the call stack to store intermediate values. The state of the loop becomes explicit if we write it as a tail-recursive function:

import scala.annotation.tailrec

@tailrec
def summer(xs: Seq[Int], acc: Int = 0): Int = xs match {
    case Seq() => acc
    case x :: rest => summer(rest, x + acc)
}

The acc (accumulator) argument represents the state here. It is not mutated, instead we create a new state for each iteration.

In fact, performing such an operation is so common that it's usually done via fold (or foldLeft, which allows the result to be of a different type):

def summer (xs: Seq[Int]): Int = (xs fold 0) (_ + _)

How does explicit state mesh with object-oriented programming? Quite well, actually: the object is the state. Think of the current object as a parameter that is invisibly being passed along in any method call. However, you never mutate the state, and instead create a new one. Careful though: this can make some data structures horribly inefficient if not designed with immutability in mind.

What does this mean for implementing a REST API? Nothing. It is your job as a programmer to decide which paradigms and patterns are suitable in any given situation. Using explicit state can have benefits, but it might also be obfuscation of what's really happening. In any case, different parts of the program can use different amounts of Functional Programming. Using FP patterns is possible even at a fairly small scale, and does not require your whole program to be written in absolute “purity”.

Functional programming is not about having no state. Instead, all that immutability stuff is about making state explicit. A simple example is adding a list of numbers. In Python, we would do something like this:

xs = [1, 2, 3, 4, 5]
sum = 0
for x in xs:
  sum += x

(Actually, we'd use the sum builtin, but this is just an example). This loop is stateful, because we mutate the sum variable at each iteration. The sum variable is not referentially transparent, because it points to different values at different points of time. The state is encoded in the control flow. Scala is not dogmatic about functional programming, and allows you to write code in a stateful way. However, you are encouraged to limit implicit state.

How could we make state explicit, or get rid of it when summing numbers? We can define the sum of a list as zero if the list is empty, and the first element plus the sum if the remaining elements otherwise. Note that this is a recursive definition. In Scala, we'd write it as

val xs = Seq(1, 2, 3, 4, 5)

def summer(xs: Seq[Int]): Int = xs match {
  case Seq() => 0
  case x :: rest => x + summer(rest)
}

val sum = summer(xs)

Note that while we have made the for … in … loop recursive, there still is no obvious state. This is because the recursive function uses the call stack to store intermediate values. The state of the loop becomes explicit if we write it as a tail-recursive function:

import scala.annotation.tailrec

@tailrec
def summer(xs: Seq[Int], acc: Int = 0): Int = xs match {
    case Seq() => acc
    case x :: rest => summer(rest, x + acc)
}

The acc (accumulator) argument represents the state here. It is not mutated, instead we create a new state for each iteration.

In fact, performing such an operation is so common that it's usually done via fold (or foldLeft, which allows the result to be of a different type):

def summer (xs: Seq[Int]): Int = (xs fold 0) (_ + _)

How does explicit state mesh with object-oriented programming? Quite well, actually: the object is the state. Think of the current object as a parameter that is invisibly being passed along in any method call. However, you never mutate the state, and instead create a new one. Careful though: this can make some data structures horribly inefficient if not designed with immutability in mind.

What does this mean for implementing a REST API? Nothing. It is your job as a programmer to decide which paradigms and patterns are suitable in any given situation. Using explicit state can have benefits, but it might also be obfuscation of what's really happening. In any case, different parts of the program can use different amounts of Functional Programming. Using FP patterns is possible even at a fairly small scale, and does not require your whole program to be written in absolute “purity”.

1
source | link

Functional programming is not about having no state. Instead, all that immutability stuff is about making state explicit. A simple example is adding a list of numbers. In Python, we would do something like this:

xs = [1, 2, 3, 4, 5]
sum = 0
for x in xs:
  sum += x

(Actually, we'd use the sum builtin, but this is just an example). This loop is stateful, because we mutate the sum variable at each iteration. The sum variable is not referentially transparent, because it points to different values at different points of time. The state is encoded in the control flow. Scala is not dogmatic about functional programming, and allows you to write code in a stateful way. However, you are encouraged to limit implicit state.

How could we make state explicit, or get rid of it when summing numbers? We can define the sum of a list as zero of the list is empty, and the first element plus the sum if the remaining elements otherwise. Note that this is a recursive definition. In Scala, we'd write it as

val xs = Seq(1, 2, 3, 4, 5)

def summer(xs: Seq[Int]): Int = xs match {
  case Seq() => 0
  case x :: rest => x + summer(rest)
}

val sum = summer(xs)

Note that while we have made the for … in … loop recursive, there still is no obvious state. This is because the recursive function uses the call stack to store intermediate values. The state of the loop becomes explicit if we write it as a tail-recursive function:

import scala.annotation.tailrec

@tailrec
def summer(xs: Seq[Int], acc: Int = 0): Int = xs match {
    case Seq() => acc
    case x :: rest => summer(rest, x + acc)
}

The acc (accumulator) argument represents the state here. It is not mutated, instead we create a new state for each iteration.

In fact, performing such an operation is so common that it's usually done via fold (or foldLeft, which allows the result to be of a different type):

def summer (xs: Seq[Int]): Int = (xs fold 0) (_ + _)

How does explicit state mesh with object-oriented programming? Quite well, actually: the object is the state. Think of the current object as a parameter that is invisibly being passed along in any method call. However, you never mutate the state, and instead create a new one. Careful though: this can make some data structures horribly inefficient if not designed with immutability in mind.

What does this mean for implementing a REST API? Nothing. It is your job as a programmer to decide which paradigms and patterns are suitable in any given situation. Using explicit state can have benefits, but it might also be obfuscation of what's really happening. In any case, different parts of the program can use different amounts of Functional Programming. Using FP patterns is possible even at a fairly small scale, and does not require your whole program to be written in absolute “purity”.