DevInSantos 2015 - There is life beyond OOP

Slide 1

Slide 1 text

THERE'S LIFE BEYOND OOP Renan Ranelli

Slide 2

Slide 2 text

(OR …) WHY YOU SHOULD CARE ABOUT FUNCTIONAL PROGRAMMING Renan Ranelli

Slide 3

Slide 3 text

Renan Ranelli (Milhouse)

Slide 4

Slide 4 text

Software Engineer @ Renan Ranelli (Milhouse)

Slide 5

Slide 5 text

Software Engineer @ Renan Ranelli (Milhouse)

Slide 6

Slide 6 text

Renan Ranelli (Milhouse)

Slide 7

Slide 7 text

AGENDA • Why OOP {was,is} so successful? • What is happening in the hardware industry? • Why are people talk so much about functional programming (FP)? • There is no FP vs OOP dichotomy • FP is not about concurrency & multicore (!!)

Slide 8

Slide 8 text

WHY {WAS,IS} OOP SO SUCCESSFUL?

Slide 9

Slide 9 text

WHY {WAS,IS} OOP SO SUCCESSFUL? • Object Oriented Programming gives you a “natural” way to talk about and structure programs, and offers many ways to achieve polymorphism and composition • A big chunk of “software engineering” disciplines being tailored to work with this paradigm (requirements, analysis, UML, design, etc.) • History: being at the right place at the right time with the right people (?)

Slide 10

Slide 10 text

WHY {WAS,IS} OOP SO SUCCESSFUL?

Slide 11

Slide 11 text

WHY {WAS,IS} OOP SO SUCCESSFUL?

Slide 12

Slide 12 text

WHY {WAS,IS} OOP SO SUCCESSFUL? • The main reason IMO: the existence of Sun & Microsoft that pushed their `Java` and `.Net` platforms.

Slide 13

Slide 13 text

MEANWHILE, WHAT IS HAPPENING IN THE HARDWARE INDUSTRY?

Slide 14

Slide 14 text

WHAT IS HAPPENING IN THE HARDWARE INDUSTRY? • You should google “no more free lunch” and read the first article. Seriously.

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

WHAT IS HAPPENING IN THE HARDWARE INDUSTRY? • You should google “no more free lunch” and read the first article. Seriously. • Since I'm already here, I'll give you a primer: – CPU clock is not getting exponentially faster – Transistor number is still growing rapidly – No performance gain for single threaded apps – Concurrency is the next major revolution in how we write software

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

> Concurrency is the next major revolution in how we write software > Applications will increasingly need to be concurrent if they want to fully exploit continuing exponential CPU throughput gains > Efficiency and performance optimization will get more, not less, important

Slide 19

Slide 19 text

This was written in March 2005

Slide 20

Slide 20 text

2005

Slide 21

Slide 21 text

In 2005: – Java 5 was hot news. – Windows XP. Vista only in 2007. – No AWS, Twitter, Netflix. – Ruby on Rails launched in December 13th. – Youtube was just founded. – We never have heard of Justin Bieber – I was playing Gunbound & Tibia. No money for WoW.

Slide 22

Slide 22 text

This was written in March 2005

Slide 23

Slide 23 text

WHAT IS HAPPENING IN THE HARDWARE INDUSTRY? • Every programming language created in the last few years has a strong focus in making concurrent programming easier: – Scala, Clojure – Elixir – Go, Rust – The recent popularity boom of Erlang & Haskell – Kotlin, Nim, Pony, Crystal, etc...

Slide 24

Slide 24 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING?

Slide 25

Slide 25 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING? • First of all, functional programming is not a new thing • Here is a list of “functional languages” and the year they were introduced: – 1960 → Lisp – 1973 → ML – 1980s → Lazy langs: Miranda, KRC, SASL, Orwell... – 1986 → Erlang – 1990 → Haskell 1.0

Slide 26

Slide 26 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING? • There is no consensus on what actually means for a language to be “functional”. We prefer talking about “functional style”, which rely heavily on: – Functions as first class citizens – Immutability of data • These are fundamental to avoid types of race conditions

Slide 27

Slide 27 text

Process Context Process Context HEAP (SHARED MEMORY) Stack2 Thread 2 Stack3 Thread 3 Processor Core Stack1 Thread 1

Slide 28

Slide 28 text

Process Context Process Context Processor Core HEAP (SHARED MEMORY) Stack1 Thread 1 Stack2 Thread 2 Stack3 Thread 3

Slide 29

Slide 29 text

Process Context Process Context Processor Core HEAP (SHARED MEMORY) Stack1 Thread 1 Stack2 Thread 2 Stack3 Thread 3

Slide 30

Slide 30 text

Process Context Process Context Processor Core Processor Core HEAP (SHARED MEMORY) Stack1 Thread 1 Stack2 Thread 2 Stack3 Thread 3

Slide 31

Slide 31 text

Process Context Process Context HEAP (SHARED MEMORY) Stack1 Thread 1 Stack2 Thread 2 Stack3 Thread 3 Processor Core Processor Core

Slide 32

Slide 32 text

Process Context Process Context HEAP (SHARED MEMORY) Stack1 Thread 1 Stack2 Thread 2 Stack3 Thread 3 Processor Core Processor Core

Slide 33

Slide 33 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING?

Slide 34

Slide 34 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING? • The “functional style” relies heavily on: – Functions as first class citizens – Immutability of data

Slide 35

Slide 35 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING?

Slide 36

Slide 36 text

• If data is immutable, this problem is impossible, by construction

Slide 37

Slide 37 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING? • Covariance of generic collection types:

Slide 38

Slide 38 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING? • (code demo)

Slide 39

Slide 39 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING? • (code demo)

Slide 40

Slide 40 text

• If data is immutable, this problem is impossible, by construction

Slide 41

Slide 41 text

WHY ARE PEOPLE TALKING SO MUCH ABOUT FUNCTIONAL PROGRAMMING? • This is one of the cases where immutability makes your life easier. It will also enable the compiler/runtime to perform a lot of optimizations that are just downright impossible in languages like Java, Ruby, Python, C#, etc.

Slide 42

Slide 42 text

• IMPORTANT: IMMUTABILITY DOES NOT IMPLY LACK OF STATE (!) – (as I will show in a simple demo)

Slide 43

Slide 43 text

THERE IS NO OOP VS FP DICHOTOMY

Slide 44

Slide 44 text

THERE IS NO OOP VS FP DICHOTOMY • You probably has heard the following: – Good OO design dictates that an object has a single responsibility – Good OO design dictates that an object should have few methods in its public interface – Good OO design dictates that an object limit the number of other objects it interacts with

Slide 45

Slide 45 text

THERE IS NO OOP VS FP DICHOTOMY • In the limit … – Objects should interact with few other objects – Objects should contain only a single public method, which does one single thing • This “object” is indistinguishable from a closure

Slide 46

Slide 46 text

THERE IS NO OOP VS FP DICHOTOMY • (what is a closure ?)

Slide 47

Slide 47 text

THERE IS NO OOP VS FP DICHOTOMY • Closures are behavior with attached data • Objects are data with attached behavior • The concepts are dual (which means you can describe one in terms of the other)

Slide 48

Slide 48 text

THERE IS NO OOP VS FP DICHOTOMY • You may have heard that functional programming is hard • I strongly disagree. Object systems are hard, and you don't see people whining about them • What is hard is changing your paradigm, and getting out of your comfort zone.

Slide 49

Slide 49 text

FP IS *NOT* ABOUT CONCURRENCY AND MULTICORE (!!)

Slide 50

Slide 50 text

(OR …) WHERE TO GO FROM NOW

Slide 51

Slide 51 text

WHERE TO GO FROM NOW • Although FP helps a lot in writing concurrent software, it is by no means limited to this. • Many design patterns common to object oriented languages are downright irrelevant with functional languages • Many problems are much better described in functional idioms (google for “the expression problem”)

Slide 52

Slide 52 text

FP IS *NOT* ABOUT CONCURRENCY AND MULTICORE (!!) ● Google for “peter norvig design patterns dynamic”

Slide 53

Slide 53 text

WHERE TO GO FROM NOW • Functional Reactive Programming is a great to organize and structure programs that must react to user input. Check out Elm for a conundrum of amazing ideas. • You don't need to abandon OO to use functional programming: Scala, C#, F# and many others let you mix and match according to your tastes.

Slide 54

Slide 54 text

WHERE TO GO FROM NOW • Many great ideas like Actor systems, software transactional memory, persistent data structures, parser combinators, etc where popularized and “discovered” in the functional community • There is a lot of nice things happening out there. • Get out of your box

Slide 55

Slide 55 text

IF YOU WANT EXPAND YOUR MIND & LEARN MORE • Take Prof. Dan Grossman's “Programming Languages” course on Coursera • Take Martin Odersky's “Functional programming principles in Scala” course on Coursera • Take Erik Meijer's “Functional programming” course on Edx. • … learn Haskell • … write your own Lisp interpreter