TDC2016 SP - There's life beyond OOP

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.

4569aec00cb223b3fbf484f9e7ba1256?s=128

Renan Ranelli

July 06, 2016
Tweet

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.
  11. None
  12. None
  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 .
  15. None
  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

  19. 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
  45. None
  46. None
  47. None
  48. Immutability

  49. Immutability If data is immutable, the problem described below (read,

    edit, write) is *impossible by construction*
  50. None
  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.
  67. None
  68. None
  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 @