Tweet
Tweet

Slide 1

Slide 1 text

The e’s life e o d OOP Renan Ranelli

Slide 2

Slide 2 text

(what is FP and why you should care) Renan Ranelli

Slide 3

Slide 3 text

Senior software engineer @ Milhouse (@renanranelli)

Slide 4

Slide 4 text

Milhouse (@renanranelli) Senior software engineer @

Slide 5

Slide 5 text

Milhouse (@renanranelli)

Slide 6

Slide 6 text

Agenda  Why OOP {was,is} so successful?  What is happening in the hardware industry?  Why are people talking so much about functional programming?  Immutability  There is no FP vs OO dichotomy  Where to go next

Slide 7

Slide 7 text

Disclaimer & objectives  This is a i t odu to talk. Do ’t e pe t profunctors and comonads.  I will tell you what is concurrency, why it is important and how FP is relates to it.  B the e d of this talk, I hope ou ill e i spi ed to take a look at fu tio al p og a i g stuff, a d ot dis iss OO as so ethi g i t i si all ad  You should ot e s a ed of FP. It’s u h o e fa ilia tha ou thi k it is.

Slide 8

Slide 8 text

Why {was,is} OOP so successful?

Slide 9

Slide 9 text

Why {was,is} OOP so successful? • People say that: o O je t O ie ted P og a i g gi es ou a atu al a to talk a out a d st u tu e programs. It also offers *many* ways to achieve polymorphism and composition o A ig pa t of soft a e e gi ee i g dis ipli es ei g tailo ed a d pe fe ted to work with this paradigm (requirements, analysis, UML, design, etc.) o History: Being at the right place at the right time (?)

Slide 10

Slide 10 text

Why {was,is} OOP so successful? • I actually think differently. I think OOP is successful because: o They teach us at school about it. o The e is so u h al ead do e . li a ies, f a e o ks, stackoverflow uestio s … o We do ’t k o alte ati es. We do ’t look e o d ou a k a d. o Sun & Microsoft invested enormous amounts of marketing money on convincing you that it is *the right way* to build software.

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

Meanwhile, in hardware-la d …

Slide 14

Slide 14 text

Meanwhile in hardware-la d … You should google the f ee lu h is o e a d ead the fi st esult. “e iousl .

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Meanwhile in hardware-la d … You should google the f ee lu h is o e a d ead the fi st esult. “e iousl . • “i e e a e al ead he e, I’ll gi e ou the TL;DR: • CPU Clock is not getting faster • No performance gain for sequential singlet-hreaded apps • Concurrency is the next major revolution in how we write software

Slide 17

Slide 17 text

Meanwhile in hardware-la d … Efficiency and performance optimization will get *more*, not less, important.

Slide 18

Slide 18 text

This was written in March 2005

Slide 19

Slide 19 text

2005

Slide 20

Slide 20 text

In 2005: o Java 5 was hot news. o Windows XP. No vista till 2007. o No AWS, Twitter or Netflix. o No Stack Overflow (!!) o Youtube was just founded. o Ruby on Rails 1.0 would only launch in December 13th. o The world did not know Justin Bieber.

Slide 21

Slide 21 text

In 2005: o Java 5 was hot news. o Windows XP. No vista till 2007. o No AWS, Twitter or Netflix. o No Stack Overflow (!!) o Youtube was just founded. o Ruby on Rails 1.0 would only launch in December 13th. o The world did not know Justin Bieber.

Slide 22

Slide 22 text

Understanding Concurrency:

Slide 23

Slide 23 text

Understanding Concurrency:

Slide 24

Slide 24 text

Understanding Concurrency: T o tasks e e ute o u e tl he the a sta t, execute and finish in time periods that *overlap* “u ’s guide to ultith eaded p og a i g 2000~ ish)

Slide 25

Slide 25 text

These are happening SERIALLY

Slide 26

Slide 26 text

These are happening *concurrently*

Slide 27

Slide 27 text

These are happening *concurrently*

Slide 28

Slide 28 text

These are happening *concurrently*

Slide 29

Slide 29 text

These are happening IN PARALLEL But *not* Concurrently (!) (there is no possible overlap)

Slide 30

Slide 30 text

Why does FP have to do with *that* ?

Slide 31

Slide 31 text

Why are they talking about fp ? As a consequence, every programming language created since then has made *concurrency* a major concern:  Scala, Clojure  Elixir  Go, Rust  Kotlin, Nim, Po , C stal …  We rediscovered Haskell & Erlang

Slide 32

Slide 32 text

Why are they talking about fp ? **BUT**: Functional programming is *not* a new thing. 1960 -> Lisp 1973 -> ML 1980s -> Lazy langs: Miranad, KRC, SASL, Orwell 1986 -> ERLANG (!) 1990 -> Haskell 1.0

Slide 33

Slide 33 text

Why are they talking about fp ? Have we finally understood that categories, monoids, profuctors, comonads and semigroups are _the right wayTM_ to build software??

Slide 34

Slide 34 text

_NO_

Slide 35

Slide 35 text

Why are they talking about fp ? I’ a engineer. I do ’t a e a out ho eautiful a d/o elega t the ode is . I care about performance, reliability, understandability. Profunctors give me none of that.

Slide 36

Slide 36 text

Why are they talking about fp ? http://blog.plataformatec.com.br/2016/05/beyond-functional-programming-with- elixir-and-erlang/

Slide 37

Slide 37 text

Why are they talking about fp ? http://blog.plataformatec.com.br/2016/05/beyond-functional-programming-with- elixir-and-erlang/

Slide 38

Slide 38 text

Why are they talking about fp ? The fu tio al st le elies hea il o: - Functions as first class citizens - Immutability of all data The latter allows us to avoid many *race conditions*. The former allows us not to go insane while doing so.

Slide 39

Slide 39 text

HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0

Slide 40

Slide 40 text

HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0

Slide 41

Slide 41 text

HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0

Slide 42

Slide 42 text

HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0

Slide 43

Slide 43 text

HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0

Slide 44

Slide 44 text

HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

Immutability

Slide 49

Slide 49 text

Immutability If data is immutable, the problem described below (read, edit, write) is *impossible by construction*

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

Immutability Is a tuall a ge e al good ad i e e e he e, e e i OOP- land) I uta le o je ts a e si ple. Classes should e i uta le u less the e’s a e good easo to ake the uta le. If a class cannot be made immutable, limit its mutability as u h as possi le Joshua Bloch: Effective Java (2001)

Slide 52

Slide 52 text

Immutability Is a tuall a ge e al good ad i e e e he e, e e i OOP-land) Whe desig i g a s ste it’s i po ta t to disti guish between values […] a d objects […]. Values are immutable instances that model fixed ua tities. The ha e o ide tit . Steve Freeman & Nat Pryce: Growing OO Software, guided by tests (2009)

Slide 53

Slide 53 text

Immutability Fu tio al p og a i g is p og a i g ith alues (almost all the time)

Slide 54

Slide 54 text

Immutability

Slide 55

Slide 55 text

Immutability Immutability **does not** imply absence of state (!)

Slide 56

Slide 56 text

Immutability Other awesome things immutability brings us: • Proper Covariance of collection types. • Many performance optimizations: (sub-expression elimination, memoization, yadda yadda) • Ti e t a eli g (there is probably a talk about this today)

Slide 57

Slide 57 text

Functions as 1st class citizens

Slide 58

Slide 58 text

Fu tio s + e i o e t = losu e

Slide 59

Slide 59 text

Fu tio s + e i o e t = losu e

Slide 60

Slide 60 text

Fu tio s + e i o e t = losu e

Slide 61

Slide 61 text

Fu tio s + e i o e t = losu e

Slide 62

Slide 62 text

Fu tio s + e i o e t = losu e

Slide 63

Slide 63 text

Fu tio s + e i o e t = losu e

Slide 64

Slide 64 text

Closure: • A *closure* is behavior with attached data.

Slide 65

Slide 65 text

Objects: • OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late- i di g of all thi gs. […] Alan Kay •=> Objects are data with attached behavior

Slide 66

Slide 66 text

There is no dichotomy • A *closure* is behavior with attached data. • An *object* is data with attached behavior. Rich closures gravitate towards objects. Slim objects gravitate towards closures.

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

There is no dichotomy • You a ha e hea d that fu tio al p og a i g is ha d . • I strongly disagree. Object systems are much harder & complex. • Thi gs a e eas e ause the a e fa ilia .

Slide 70

Slide 70 text

Closing remarks

Slide 71

Slide 71 text

Where to go from now? • You do ’t eed to a a do OO to use the fu tio al st le. “ee F#, C# a d “ ala fo i e le ds . • If ou’ e o e i to f o te d stuff, he k Clojurescript & Elm.

Slide 72

Slide 72 text

Where to go from now? • If you like moocs, you must *absolutely* see prof. Dan G oss a ’s P og a i g La guages ou se o coursera. •Martin Odersky also has courses on Scala in coursera. All of them are awesome. •E ik Meije gi es a I t odu tio to Fu tio al P og a i g ith Haskell ou se o Edx. •Write your own Lisp.

Slide 73

Slide 73 text

Where to go from now? • The o e theorical aspe ts of fu tio al p og a i g ha e a lot to tea h ou. You do ’t eed functors a d o ads to get the jo do e , ut pu sui g those ideas is a rewarding experience in itself. •Old ideas become new again. There is so much happening out there. Get out of your box.

Slide 74

Slide 74 text

Obrigado!

Slide 75

Slide 75 text

milhouseonsoftware.com @renanranelli /rranelli Milhouse @