@colorGoldenRod
What should we @colorIndianRed
@colorGoldenRod
@colorGoldenRod
How do we solve problems? We decompose bigger problems into smaller problems. If the smaller problems are still too big, we decompose them further, and so on.
Finally, we write code that solves all the small problems.
And then comes the essence of programming: we compose those pieces of code to create solutions to larger problems.
Decomposition wouldn’t make sense if we weren’t able to put the pieces back together. - Bartosz Milewski
val toS : Int => String = n => {
appendAll("log.txt", "some content")
n.toString
}
val list = collection.mutable.ListBuffer[Int]()
val toS : Int => String = n => {
list += n
if (list.size < 42) n.toString
else "Yo!"
}
- hide inputs and outputs
- destroy testability
- destroy composability
FP is about @colorIndianRed or @colorGoldenRod side-effects
see “function” as the @colorIndianRed one:
- @colorGoldenRod: it must yield a value for every possible input
- @colorGoldenRod: it must yield the same value for the same input
- @colorGoldenRod: it’s only effect must be the computation of its return value
all functions become @color[GoldenRod](referentially transparent)
An @color[GoldenRod](expression can be replaced) with
its corresponding value @color[IndianRed](without changing)
the program's behavior
it means these two programs are @colorGoldenRod
val y = foo(x)
val z = y + y
val z = foo(x) + foo(x)
functions get an @color[IndianRed](extraordinary quality) boost:
- easier to @colorGoldenRod
- easier to @colorGoldenRod
- easier to @colorGoldenRod
- easier to @colorGoldenRod
@colorGoldenRod
\[ x(y + z) = (xy) + (xz) \]