> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/general-paradigms/programming-types/functional-programming.md). # 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 * * Clojure * Erlang * Haskell * OCaml * F# (hybrid) * Scala (hybrid) * ## Properties * 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 ## Pure functions * 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. ### side effects * 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. ## Immutability * 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 not to use * 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 ## Advantages * * ## Properties * ## Drawbacks of functional programming * * ## Glossary * ## Links * * [The Three Paradigms - Uncle Bob](https://blog.cleancoder.com/uncle-bob/2012/12/19/Three-Paradigms.html) * [FP vs OO](https://blog.cleancoder.com/uncle-bob/2018/04/13/FPvsOO.html) * * * * * * * * * *