Anúncio

Functional Leap of Faith (Keynote at JDay Lviv 2014)

Consulting Engineer em Substrate Software Services
8 de Sep de 2014
Anúncio

Mais conteúdo relacionado

Similar a Functional Leap of Faith (Keynote at JDay Lviv 2014)(20)

Anúncio
Anúncio

Functional Leap of Faith (Keynote at JDay Lviv 2014)

  1. Functional Leap of Faith Tomer Gabel, Wix JDay Lviv 2014
  2. Through the Looking Glass 20 years ago… • C/C++ rule the market [1] • First release of Java [1] TIOBE Index (historical data)
  3. … since then?* • C and Java are neck-and-neck • Virtual machines are everywhere • Garbage collection is everywhere • OOP is everywhere * Not exhaustive
  4. Virtual Machines 1967 BCPL 1978 UCSD p-System 1994 JVM 2014 Everywhere!
  5. Garbage Collection 1960 Formalized[1] 1970s Research 1994 JVM 2014 Everywhere! [1] Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I
  6. Object-Oriented Programming 1967 Simula 67 1980 Smalltalk 80 1983 C++ 2014 Everywhere!
  7. Advances take decades to become mainstream
  8. Market Growth[1] 3000 2500 2000 1500 1000 500 0 1975 1980 1985 1990 1995 2000 2005 2010 2015* 2020* Units (Millions) [1] eTForecasts Worldwide PC Market Research Report
  9. 3000 2500 2000 1500 1000 500 0 1975 1980 1985 1990 1995 2000 2005 2010 2015* 2020* Units (Millions) Market Growth • Structured Programming • Module Systems • Dynamic Memory Allocation
  10. 3000 2500 2000 1500 1000 500 0 1975 1980 1985 1990 1995 2000 2005 2010 2015* 2020* Units (Millions) Market Growth • Garbage Collection • OOP • VMs and JIT
  11. 3000 2500 2000 1500 1000 500 0 1975 1980 1985 1990 1995 2000 2005 2010 2015* 2020* Units (Millions) Market Growth You are here!
  12. What’s holding us back?
  13. The Market has Shifted • SaaS is the norm • Shorter time to market • Latency requirements are stricter • Availability is business-critical
  14. The Free Lunch is Over[1] [1] The Free Lunch is Over, Herb Stutter (Dr. Dobb's Journal, 2005) • CPUs aren’t getting (much) faster • Rather, they’re getting parallel • Concurrency is the new kid on the block
  15. Datasets are Getting Bigger • Terabyte-scale data is common • Computation demand – NoSQL – Big Data • Specialized hardware (SAN) is a hindrance
  16. We need new abstractions.
  17. Three desirable attributes:
  18. Today’s systems are highly available & reliable. Tomorrow’s abstraction must… encourage correct code.
  19. Complexity is the Mind Killer • Complex system  bigger codebase • More code  more bugs • We want less code • We want correct code
  20. Control flow  Data flow We need to invert our thinking.
  21. How  What We need to invert our thinking.
  22. Control flow describes the how List<Person> adults(List<Person> in) { ArrayList<Person> out = new ArrayList<>(); for (Person p : in) if (p.getAge() >= 18) out.add(p); return out; }
  23. Data flow describes the what List<Person> adults(List<Person> in) { return in.stream() .filter(p -> p.age >= 18) .collect(Collectors.toList()); }
  24. “What” is Better • Focuses on the problem • Reduces accidental complexity • Decouples intent from execution
  25. Today’s systems are highly concurrent. Tomorrow’s abstraction must… encourage immutability.
  26. The Case for Immutability • Inherently thread-safe • Referentially transparent • Easier to reason about!
  27. Today’s systems are horizontally scalable. Tomorrow’s abstraction must… simplify workload distribution.
  28. Distribution 101 1. Take a core computation 2. Split it out 3. Run on many nodes 4. Profit
  29. Why is this hard? • Behavior-as-data • Side effects • High-performance frameworks  Lambdas  Immutability  Akka, Hadoop, Storm…
  30. The future is functional. 1. Data flow-oriented 2. Immutable 3. Easy to distribute
  31. tomer@tomergabel.com @tomerg http://il.linkedin.com/in/tomergabel THANK YOU FOR YOUR TIME!

Notas do Editor

  1. [1] http://www.cl.cam.ac.uk/~mr10/bcplman.pdf [2] http://en.wikipedia.org/wiki/UCSD_Pascal
  2. Research includes: * Copy collector (a.k.a Cheney’s Algorithm http://en.wikipedia.org/wiki/Cheney%27s_algorithm) * Mark-sweep (table or LISP2 http://en.wikipedia.org/wiki/Mark-compact_algorithm)
  3. [1] http://www.cl.cam.ac.uk/~mr10/bcplman.pdf [2] http://en.wikipedia.org/wiki/UCSD_Pascal
  4. http://www.etforecasts.com/products/ES_pcww1203.htm
  5. Image source: https://www.flickr.com/photos/luisangel/171934213
  6. Image source: https://www.flickr.com/photos/iwb/5418874340 [1] http://www.gotw.ca/publications/concurrency-ddj.htm
  7. Image source: https://www.flickr.com/photos/zagrobot/2731084578
  8. As complexity increases… … so does your code base Less code => less bugs We need a way to write less code We need a way to write correct code
  9. Image source: http://commons.wikimedia.org/wiki/File:Uncle_Sam_(pointing_finger).jpg
  10. As complexity increases… … so does your code base Less code => less bugs We need a way to write less code We need a way to write correct code
  11. Image source: https://www.flickr.com/photos/60848944@N00/3537064556
  12. As complexity increases… … so does your code base Less code => less bugs We need a way to write less code We need a way to write correct code
  13. Image source: http://en.wikipedia.org/wiki/Supercomputer#mediaviewer/File:Wide-angle_view_of_the_ALMA_correlator.jpg
Anúncio