from imperative to functional programming (for absolute beginners)
Post on 24-Jul-2015
125 Views
Preview:
TRANSCRIPT
History of Computing• World War II — US Army & Navy artillery ballistics
• Manual calculations not feasible
• In February 1944 IBM delivered Automatic Sequence Controlled Calculator (ASCC), a.k.a. Mark I — weighed 5 tons, had 750,000 parts and could perform 3 operations per second
What’s the Difference?
• Programming using declarative paradigm is like explaining your problem to a mathematician
• Programming using imperative paradigm is like explaining your problem to an idiot
• Granted, it is much easier to explain your problem to an idiot, because the idiot doesn’t have any opinions and will not push back
Functional Paradigm• Set of ideas, not a set of strict guidelines
• Deals with calculations (algebra)
• Uses functions to do that
• Doesn’t use variables
• Doesn’t use assignments
• No conditional statements
• No loops
FP Outlaws Destruction
• Not possible to destroy anything within the FP world
• The only possible thing is production
Stateless• Ignorant of the past
• Functional programs perform every task as if for the first time ever (idempotency)
• Functional programs do not maintain state
• “Good thing about telling the truth is that you don’t have to remember anything” — Mark Twain
Immutable• Facts remain facts, and facts cannot be
modified
• The fact that IBM Mark I was shipped in February 1944 remains an immutable fact
• If nothing in the functional program varies, the very notion of variables becomes meaningless
• It is impossible to make a change in place when doing FP (destruction is outlawed)
Isn’t that totally unrealistic?
• If it is impossible to make any destructive action (such as mutating a value assigned to a variable) when writing a functional program, how do we account for the changes that occur in real life?
Example• A customer applies for a loan in June 2014 and gets adjudicated
with Equifax credit score 690
• The same customer applies again for a loan 6 months later (in December 2014) and this time gets adjudicated with the score of 530
• Obviously, there’s been a real change
• How do we record that change using FP?
• We leave the old fact from June 2014 immutable
• We create a new fact that is valid for December 2014 (the only allowed operation is production)
• Both facts characterize this customer
Mutability is Evil
• GOTO is evil because it makes us scratch our heads “how did I get to this point of execution?”
• Mutability is evil because it makes us scratch our heads “how did I get to this state?”
Programming Is About Transforming Data
• We don’t hack existing data in place
• Instead, we always transform it into something new
• For example, we never capitalize a string, we return a capitalized copy of a string
Performance Implications?
• At a first glance it may seem as if immutability is inefficient (keep the old value and produce a new value instead of simply overwriting the old value)
• Actually, the reverse is true — it improves efficiency and performance
• FP uses lots and lots of processes, each with its own heap and the data gets distributed among many heaps, resulting in much faster garbage collection
What Are Functions?
• Binary relations that map arguments to results
• Pure functions simply return results and do not produce any side effects
What Are Side Effects?
• Modifying a value in-place (i.e. mutating a variable)
• Modifying a data structure in-place
• Setting a field on an object
• Throwing an exception or halting with an error
• Printing to the console or reading user input
• Reading from or writing to a file
• Drawing on the screen
Ground Rules for FP
• Each and every function must accept at least one argument
• Each and every function must return either a value or another function
• No loops!
Switching from Imperative to FP
• Any time we notice repetitious code, we notice a candidate for a function
• The idea is to break it down to basic, atomic functions that are doing one thing only
FP is Unit Tester’s Wet Dream!
• Functions are idempotent (same as HTTP GET)
• Consequently, functions don’t have side effects
• It is impossible to modify a value in place (non-destructive)
• It is also impossible to modify a value outside function’s scope (non-destructive)
You Are Always Testing Only One Thing
• The only volatile thing to test is the return value
• No need to worry whether we’re calling functions in the right order
• No need to worry about whether we’re setting the external state properly (no preconditions)
• In imperative languages (C++, C#, Java, Ruby, etc.) checking the return value is not sufficient (imperative programs may modify external state and thus result in undesirable conditions)
Troubleshooter’s and Debugger’s Wet Dream!
• Easy to reproduce the problem because it does not depend on code that got executed before the bug happened
• If a return value of a function is wrong, it is always wrong! — the order of execution does not matter (deterministic)
Hot Fix Deployer’s Wet Dream!
• Impossible feat in the imperative world
• Unloading a class at runtime and reloading new definition — every instance of that class will become unusable (the state will be destroyed)
• In FP, because there is no state, all we have to do is run a diff between code in prod and the new version and then deploy the new code
Homoiconic
• There is no difference between source code and data
• Parse source code the same way you’d parse your data and then programmatically produce new useful code during run time
• Metaprogramming
A Few Guidelines• The foundations of programming are not
assignments, if statements and loops
• Concurrency does not need locks, semaphores, monitors etc.
• Processes are not necessarily expensive resources
• Metaprogramming is not something tacked onto a language
• In FP, = is not an assignment operator, it can be viewed as an assertion operator, and sometimes as a match operator
Higher Order Functions
• If we see that logic inside a function differs depending on the context, we break it out into a higher order function
top related