TDC2016 SP - There's life beyond OOP

Object oriented programming is undoubtedly the most used programming paradigm. However, in recent years we have seen languages so called "functional" rising in popularity and relevance. What the heck does the mean? What makes those languages "different"? Why do we hear more and more about Scala, Clojure, Erlang, Elixir and Haskell? Why should I Care?

After this talk, I hope you will understand why these questions matter and have a better understanding of their answers. Also, I hope to inspire you to look beyond your community/language/framework.

---

Orientação a objetos é sem dúvida o paradigma de programação mais utilizado. Porém, recentemente temos visto a popularização e proliferação de linguagens ditas ""funcionais"". O que raios isso significa ? O que faz essas linguagens diferentes? Porque ouvimos mais e mais falar de Scala, Clojure, Haskell e afins? /Why should I Care/? Depois desta palestra você irá compreender a resposta para essas perguntas, e porque nós, como desenvolvedores, devemos sempre estar atentos a o que acontece fora da nossa comunidade/linguagem/framework.

Transcript

1. The e’s life e o d OOP Renan Ranelli
2. (what is FP and why you should care) Renan Ranelli
3. Senior software engineer @ Milhouse (@renanranelli)
4. Milhouse (@renanranelli) Senior software engineer @
5. Milhouse (@renanranelli)
6. 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
7. 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.
8. Why {was,is} OOP so successful?
9. 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 (?)
10. 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.
13. Meanwhile, in hardware-la d …
14. 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 .
16. 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
17. Meanwhile in hardware-la d … Efficiency and performance optimization will get *more*, not less, important.
18. This was written in March 2005
20. 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.
21. 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.
22. Understanding Concurrency:
23. Understanding Concurrency:
24. 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)
25. These are happening SERIALLY
26. These are happening *concurrently*
27. These are happening *concurrently*
28. These are happening *concurrently*
29. These are happening IN PARALLEL But *not* Concurrently (!) (there is no possible overlap)
30. Why does FP have to do with *that* ?
31. 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
32. 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
33. Why are they talking about fp ? Have we finally understood that categories, monoids, profuctors, comonads and semigroups are _the right wayTM_ to build software??
34. _NO_
35. 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.
36. Why are they talking about fp ? http://blog.plataformatec.com.br/2016/05/beyond-functional-programming-with- elixir-and-erlang/
37. Why are they talking about fp ? http://blog.plataformatec.com.br/2016/05/beyond-functional-programming-with- elixir-and-erlang/
38. 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.
39. HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0
40. HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0
41. HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0
42. HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0
43. HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0
44. HEAP (global, mutable & shared state) Thread 0 Thread 2 Thread 1 Process Context Stack0 Stack2 Stack1 Core 1 Core 0
48. Immutability
49. Immutability If data is immutable, the problem described below (read, edit, write) is *impossible by construction*
51. 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)
52. 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)
53. Immutability Fu tio al p og a i g is p og a i g ith alues (almost all the time)
54. Immutability
55. Immutability Immutability **does not** imply absence of state (!)
56. 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)
57. Functions as 1st class citizens
58. Fu tio s + e i o e t = losu e
59. Fu tio s + e i o e t = losu e
60. Fu tio s + e i o e t = losu e
61. Fu tio s + e i o e t = losu e
62. Fu tio s + e i o e t = losu e
63. Fu tio s + e i o e t = losu e
64. Closure: • A *closure* is behavior with attached data.
65. 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
66. 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.
69. 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 .
70. Closing remarks
71. 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.
72. 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.
73. 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.
74. Obrigado!
75. milhouseonsoftware.com @renanranelli /rranelli Milhouse @