5. Why FP?
• I Have to Be Good at Writing Concurrent Programs
• Most Programs Are Just Data Management Problems
(why ORM?)
• More Modular
• I Have to Work Faster and Faster
• Code is written once, but read many times
6. Why FP?
• I Have to Be Good at Writing Concurrent Programs
• Most Programs Are Just Data Management Problems
(why ORM?)
• More Modular
• I Have to Work Faster and Faster
• Code is written once, but read many times
7. Why FP?
• I Have to Be Good at Writing Concurrent Programs
• Most Programs Are Just Data Management Problems
(why ORM?)
• More Modular
• I Have to Work Faster and Faster
• Code is written once, but read many times
8. Why FP?
• I Have to Be Good at Writing Concurrent Programs
• Most Programs Are Just Data Management Problems
(why ORM?)
• More Modular
• I Have to Work Faster and Faster
• Code is written once, but read many times
9. Why FP?
• I Have to Be Good at Writing Concurrent Programs
• Most Programs Are Just Data Management Problems
(why ORM?)
• More Modular
• I Have to Work Faster and Faster
• Code is written once, but read many times
10. What is FP?
• RECURSION
• ABSTRACTION
• HIGHER ORDER FUNCTIONS
• IMPACT MOST PROGRAMMING LANGUAGES
11. PROGRAMS AS FUNCTIONS
• PROGRAM = DESCRIPTION OF A SPECIFIC
COMPUTATION
• Y = F(X)
• F: X ->Y
• MATHEMATICS
• VARIABLES = ACTUAL VALUES
• NO MEMEORY ALLOCATION CONCEPT
• IMPERATIVE LANGUAGE
• VARIABLES = MEMORY LOCATIONS + VALUES
12. PROGRAMS AS FUNCTIONS
• NO LOOPS BUT RECURSION
• NO VARIABLE EXCEPT AS A NAME FOR A VALUE
• NO ASSIGNMENT OPERATION (x = x+1 ,
MEANINGLESS)
• ONLY CONSTANTS, PARAMETERS AND VALUES
13. imperative
functional
EXAMPLE
Void GCD (int u, int v, int* x) {
Int y, t, z;
z = u;
y = v;
While (y!=0) {
…
…
}
…
}
Void GCD(int u, int v) {
if(v==0)
return u;
else
return GCD(v, u%v);
}
14. NO VARIABLES, NO ASSIGNMENT
• No notion of the internal state of a function.
• Referential Transparency.
• Value Semantics.
15. FP vs Others
• Recursions instead of loops
• Pattern matching instead of “if”
• Pattern matching instead of state machines
• Information transformation instead of sequence of tasks
18. What it really means?
• Immutability is good
• No bugs (due to nasty side effects)
19. What it really means?
• Immutability is good
• No bugs (due to nasty side effects)
• Benefits from concurrency
20. What it really means?
• Immutability is good
• No bugs (due to nasty side effects)
• Benefits from concurrency
• No more messy loops
21. What it really means?
• Immutability is good
• No bugs (due to nasty side effects)
• Benefits from concurrency
• No more messy loops
• Lazy evaluation
24. Maintaining, Maintainability
• Use functional style wheretill it makes the intent more
readable.
Sort(extract(filter(having(on(Pet.class).getSpecies(), is(Dog)), pets,
on(Pet.class).getName()), on(String.class));
List<Pet> dogs =
filter(having(on(Pet.class).getSpecies(), is(Dog)), pets);
List<String> dogNames = extract(dogs, on(Pet.class).getName());
List<String> sortedDogNames = sort(dogNames, on(String.class));
25. Maintaining, Maintainability
• One liners are always not better.
Convert(pets, new Convert<Pet, VetStay>() {
@override public VetStay converter(Pet pet) {
return new VetStay(pet, new Date(), “….”);
}});
Private Converter<Pet, VetStay> toVetStay () {
@override public VetStay converter(Pet pet) {
return new VetStay(pet, new Date(), “….”);
}});
Convert(pets, toVetStay());