Functional Programming

AKA Declarative Programming
Intent of FP is for readability and understandablility
About what rather than how (procedural)
functional programming as a paradigm begins with three things, the three main concepts — actions, calculations, and data. These are mutually exclusive categories that everything falls into.
Functional programming, therefore, is programming so as to avoid these side effects wherever possible.
Functional programming imposes discipline on mutating state.
A functional language makes all data immutable by default.
FP makes code understandable by minimizing moving parts (mutating state).
Prevents reassignment
- no garbage/temp variable -> less noise
Favours expressions and immutability
Less code, fewer moving parts, fewer bugs. Easier to trace what's going on.
Easier to parallelize.
- Since the code is not performing any explicit mutation, there's nothing to protect for thread-safety.

Types

Pure functions
- The function does not change anything
- The function does not depend on anything that may change anything
  - ie passing in a non final field
  - ie passing in a object that can change (mutable fields)
functional composition
lazy evaluation
High order functions
Immutability

No side effects
- avoidance of changing state
Only acts on the inputs
Always returns the same outputs regardless the number of times called
idempotent
Should be run immediately or lazily (later on)
- if relies on pure state cannot achieve this
do not depend on anything that could change or have side effects
the output value of a function depends only on the arguments that are passed to the function, so calling a function f twice with the same value for an argument x produces the same result f(x) each time.
- impure functions
  - they depend on state that may change outside the function. This external state might be in the form of global variables, or objects, it might be in a file, or a database, or any number of other thing
  - These are side effects
- Pure functions element side effects
the function leaves the state of the world unaffected when its run.

Statements
- assign a variable, reassign a variable, call a procedure, etc.
- Statements cause side effects.
Functional programming takes this idea further, and asserts that it is better not even to modify local, private variables.

Allows of memoization
explicit mutability is avoided by the user of FP
- The compiler will use mutability
- The aspects and problems of mutability is not our problem to deal with, it's the lower level problem

When the code becomes
- messy (greater than one line lambdas )
- lots of exit points (ie exceptions)
When there are side effects
- ie dealing with external input like database, io etc
- A purely functional program, cannot take any outside input, cannot really do anything
Use of forEach()
- takes a consumer, which has side effects
- s -> {} is a pure consumer, but does nothing and useless
Alternative to consumer, is a supplier
- does not take any input and returns a value

https://alvinalexander.com/scala/fp-book/disadvantages-of-functional-programming
https://www.quora.com/What-is-the-dark-side-of-functional-programming-What-problems-are-not-suited-for-functional-programming-What-problems-arise-in-large-deployments