Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

3.
Roadmap
■ Why did OOP become so popular?
■ Why did FP become so popular?
■ Essence of FP
■ Introduction to Scala
○ How it stands between OOP and FP
■ Practical FP with Scala
○ Step by step examples
■ The good, the bad, the ugly Scala
■ Resources to learn Scala

7.
Why did OOP become popular?
■ Encapsulation? NO
■ Code re-use? NO
■ Dynamic binding? NO
■ Dependency inversion? NO
■ Liskov substitution principle? NO
■ Open-closed principle? NO
■ It’s because of the things you could do with OOP!

9.
What do Simulation & GUIs have in common?
■ Both need a way to execute a fixed API with an
unknown implementation.
■ It is possible to do that in a procedural language such
as C.
○ But it is too cumbersome!
■ So, people preferred OOP languages.
○ Because they wanted to write cool GUI widgets!
○ The other things came later.

10.
2.
Functional
Programming
Why has it gained much
popularity in recent years?

12.
What about Functional Programming?
■ These alone are not enough for
mainstream adoption.
○ After all, FP has been around for 50 years!
■ Needs a catalyzer
○ Something that sparks the initial adoption until
other advantages become clear to everyone
○ Just as what OOP had for GUI widgets

14.
Triple Challenge
■ Parallel
○ How to make user of multi-cores, multi-machines?
■ Reactive
○ How to deal with asynchronous events?
■ Distributed
○ How to deal with delays and failures?
■ Mutable state is a liability for each of these!
○ Cache coherence
○ Races
○ Versioning

20.
Functional Programming
■ A programming style that models computations as the evaluation of expressions, in
contrast with imperative programming where programs are composed of statements that
change global state. Functional programming typically avoids mutable state and promotes
immutability.
■ Immutable data: FP promotes immutability. Instead of altering existing values, altered copies
are created and the original is preserved.
■ Functions are first-class citizens. They are treated like any other values.
■ Purity: A function is pure if it only depends to its arguments and contains no-side effect.
○ Side-effect: modifying global state, modifying an argument value, making IO etc.
■ Referential transparency: Pure computations yield the same result each time they invoked.
■ Lazy evaluation: Since pure computations are referentially transparent, they can be
performed at any time and still yield the same result.
○ This makes it possible to defer the computation of values until they are needed, that is,
to compute them lazily.

24.
Scala at first glance
■ Everything is an object. Every call is a method call.
1 + 5 // shorthand for 1.+(5)
■ Everything is an expression with a value.
val comment:String = if (people.isEmpty) “no-one” else “someone”
■ Semicolon is mostly optional.
■ Type-inference.
val name = “Basri” // name’s type is String
■ Value of a block or a function is the value of the last statement. return is usually omitted.
val name = { println(“Running name block”); “Basri”; }
■ Exceptions are supported but there are no checked-exceptions.
○ throw statements have a special type: Nothing
■ variable and value separation.
var age = 26; age = 27;
val name = “Basri”
name = “Kahveci” // doesn’t compile
■ Supports while and do-while but there is no for(initialize; test; update)
○ There is no break and continue keywords.
■ for loops are just a syntactic sugar.
for (n <- List(1, 2)) yield n * 2 // converted to List(1, 2) map { n => n * 2 }

31.
Scala Option Class: A fancier null value?
■ Option[A] is a container for an optional value of type A.
■ If the value of type A is present, it is an instance of Some[A], containing
the value. Otherwise, it is None.
■ It just behaves like a collection! So, you can map it, flatMap it, filter it
, chain it etc.
■ Two states: Some[A], None

39.
Lazy Evaluation
■ Strict Evaluation
○ Expressions can have a value only when their subexpressions have value.
def noreturn(x):
while True:
x = -x
return x # not reached
4 in [2, 4, noreturn(5)]
■ Non-Strict Evaluation
○ Expressions can have a value even if some of their subexpressions do not.
elem 4 [2, 4, noreturn 5]
■ Eager Evaluation
○ An expression is evaluated as soon as it is bound to a variable.
■ Lazy Evaluation
○ An expression is evaluated only when its result is needed.

43.
scala.concurrent.Future
■ A container class for a eventually-available value
■ The computation of the value might go wrong or timeout
○ When the future is completed, it may have a successful value or an
exception
■ A write-once container. Once the future is completed, it is effectively
final.
■ Much more powerful than Java’s Future
○ You can map it, flatMap it, filter it, chain it etc.

47.
FP is good for concurrency and parallelism
■ A programming style that models computations as the evaluation of expressions, in
contrast with imperative programming where programs are composed of statements that
change global state. Functional programming typically avoids mutable state and promotes
immutability.
○ No locks, No cache-invalidation, No synchronization problems
■ Immutable data: FP promotes immutability. Instead of altering existing values, altered copies
are created and the original is preserved.
○ You can share data between threads freely without data-race problems
■ Functions, Purity and Lazy Evaluation: A function is pure if it only depends to its arguments
and contains no-side effect. Since pure computations are referentially transparent, they can
be performed at any time and still yield the same result.
○ Relaxed execution order
■ Referential transparency: Pure computations yield the same result each time they invoked.
○ You can cache the result of a computation and use it afterwards

48.
■ A programming model for processing large data sets with a parallel and distributed
approach.
■ It consists 2 steps: Map, Reduce
■ The model of map and reduce functions are inspired from functional programming, but they
are not same as they are in fp
■ The key contribution is not the map and reduce functions, it is a scalable and fault-tolerant
execution engine that can be implemented based on the computation model
Map-Reduce Paradigm