Learning PureScript - Discipline is Freedom

This post is written based on the book "Functional Programming Made Easier: A Step-by-Step Guide".  

In the 1960s, the Structured Programming paradigm was developed to overcome the Spaghetti Code situation resulting from an overuse of GOTO statements.  Essentially, GOTO via Jump instructions was phased out, but there was a lot of resistance to the new Structured Programming paradigm.  Today, we are trying to replace the Imperative Programming (IP) paradigm with the Functional Programming (FP) paradigm.  There are five reasons for this: global state, mutable state, purity, optimisation, and types.  

The Global State or Global Variables in the IP paradigm allow the change of data at any time anywhere in the program, which makes it difficult to remember or reason about every possible use.  Hence, there has to be tight coupling between Global Variables, but this is easily broken by non-compliant code.  Concurrency is not enforced, and there can be variable name collisions.  Object-Oriented Programming (OOP) does not resolve the problems because we can easily create a Singleton Object that contains all our variables, which can be exposed publicly, in an emulation of Global Variables.  FP makes it impossible to have Global State.  

In IP, variables are mutable, which results in programs that are much harder to reason about because values can change drastically.  This causes programs to be more fragile.  In FP, there are no variables that are mutable.  There are only expressions linking the variable names to a fixed quantity, boolean, string or other variables.  There is referential transparency because these variables can be replaced by its values without changing the program's behaviour.  Loops in IP, which require mutable variables, become recursive functions in FP, which parallel the mathematical definitions and are easy to understand.  

In FP, there is functional purity when functions are pure, because such functions take one or more inputs, perform a computation, and returns a result.  In IP, a result may not necessarily be returned because the functions may be used to perform multiple other tasks, such as printing a value to the screen, which do not require returning a result from the computation.  These other tasks are called Side Effects.  In FP, pure functions have no Side Effects because the same input just heats up the CPU and will always produce the same output without writing to files, displaying to screen, or updating to database.  Functions with multiple parameters can also be rewritten as a set of functions each requiring only one parameter, and all of them Curried together.  

In FP, there is memoisation because the results of difficult calculations can be stored, so that the results can be looked up in their cached values instead of being recalculated.  Hence, there is optimisation.  There is also optimisation because there are no Side Effects in FP, because Side Effects cannot be cached, and when a computation resulting in a Side Effect is performed multiple times in IP, there will be multiple costly Side Effects.  

In FP, types are static because they can be checked at compile time, and hence, type errors can be detected early, refactoring can be done more easily, and IDE's can better support code development.  Hence, there is better code quality and correctness.  Static Types, as compared to Dynamic Types, limit the flexibility in coding and require explicit typing, which will result in more cumbersome code expressions.  However, some FP languages support Type Inference, which frees the programmer from explicitly declaring Types because the compiler can infer the Types based on the usage of the expressions.  Some FP languages mix type definitions with variable names, which can be more confusing.  PureScript separates the type definitions from the variable expressions.