Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The BEAM Programming Paradigm

The BEAM Programming Paradigm

#CodeBEAMSTO 2019 presentation https://codesync.global/speaker/kenji-rikitake/
Summary:
THE BEAM PROGRAMMING PARADIGM
BEAM language systems have a different set of paradigms from other programming language systems, emphasizing on the immutability of the language elements and the robust protection against the possible malfunction.
We demonstrate what kind of principles the BEAM language systems focus on by comparison with examples of other language systems and applications, including C++ and C#.

Kenji Rikitake

May 17, 2019
Tweet

More Decks by Kenji Rikitake

Other Decks in Programming

Transcript

  1. The BEAM Programming Paradigm * Kenji Rikitake | @jj1bdx #CodeBEAMSTO

    2019 * ... Or how I've been struggling to understand the well-designed ideas behind the Erlang/OTP, Elixir, and other BEAM languages and systems, while I sCll have a very hard Cme to learn "object-oriented" programming languages #CodeBEAMSTO 2019 / Kenji Rikitake 1
  2. Programming paradigm? What is that? Is it about a programming

    paradise? #CodeBEAMSTO 2019 / Kenji Rikitake 3
  3. Paradigm = pa+ern + worldview 1 • A typical example

    or pa0ern of something; a model • A worldview underlying the theories and methodology of a par;cular scien;fic subject 1 New Oxford American Dic3onary, macOS 10.14.4 #CodeBEAMSTO 2019 / Kenji Rikitake 4
  4. Programming paradigm, shown in Wikipedia Programming paradigms are a way

    to classify programming languages based on their features. — Wikipedia #CodeBEAMSTO 2019 / Kenji Rikitake 5
  5. Languages -> paradigms -> concepts • Many languages belong to

    one paradigm • A languages may have many paradigms available • A paradigm may have many concepts Peter Van Roy states there are 27 different programming paradigms 2 2 Peter Van Roy: Programming Paradigms for Dummies: What Every Programmer Should Know, 2009, SecBon 2 #CodeBEAMSTO 2019 / Kenji Rikitake 6
  6. Programming paradigm: Language pa)erns, worldview, and features Simplified characteris0cs of

    the features Design philosophy #CodeBEAMSTO 2019 / Kenji Rikitake 7
  7. Lagom: not too much, not too li0le, just right Lagom

    är bäst Just the right amount is best / enough is as good as a feast 3 3 Wiki&onary entry of "Lagom är bäst" #CodeBEAMSTO 2019 / Kenji Rikitake 10
  8. Lagom in philosophy த༱ / Zhōngyōng, Chu-yaw Confucianism: Doctrine of

    the Mean μεσότης / mesotes Aristotle: Golden Mean #CodeBEAMSTO 2019 / Kenji Rikitake 11
  9. Quote from Programming Erlang 4 4 Joe Armstrong, "Programming Erlang",

    Second Edi7on, Pragma7c Bookshelf, 2013, Sec7on 26.3, "Parallelizing Sequen7al Code" #CodeBEAMSTO 2019 / Kenji Rikitake 12
  10. Computer is as greedy as people: an3-lagom • People want

    fast ac-ons: more speed in less -me • Speed-first programming: cu9ng corners, less secure • People want more features (really?) • Feature bloat: bloatware, soBware inefficiency • Less stable, safe, and secure soBware #CodeBEAMSTO 2019 / Kenji Rikitake 13
  11. Lagom: accuracy transcends speed • Safety transcends speed • Simplicity

    transcends rich features • Stability transcends convenience ... these targets are more easily actualized by thinking a bit about how lagom your so7ware is ... and these are the phisolophy of the BEAM programming paradigm #CodeBEAMSTO 2019 / Kenji Rikitake 14
  12. Erlang's programming paradigms 5 • Func&onal programming • Message-passing concurrent

    programming • Mul&-agent programming (Erlang processes) • Some shared states (Process dic&onaries, ETS, Mnesia) 5 Peter Van Roy: Programming Paradigms for Dummies: What Every Programmer Should Know, 2009, Figure 2 (Taxonomy of programming paradigms) and Table 1 (Layered structure of a definiMve programming language) #CodeBEAMSTO 2019 / Kenji Rikitake 15
  13. A hidden BEAM programming paradigm and design: safety first, speed

    second 6 • Strong enforcement of immutability • deep-copied variables, no references • ... Programmers s;ll can write dangerous code if needed 6 Kenji Rikitake, Erlang and Elixir Fest 2018 Keynote Presenta<on, 16-JUN-2018, Tokyo, Japan #CodeBEAMSTO 2019 / Kenji Rikitake 16
  14. Immutability 7 • Once the value is stored, it cannot

    be changed • No mutable variables on either Erlang or Elixir, unless explicitly stated as an external func1on (e.g., ETS) or processes • Immutability makes debugging easier because all stored values of created objects during ac>ons remain untouched 7 José Valim, Comparing Elixir and Erlang variables, Plataformatec blog, January 12, 2016 #CodeBEAMSTO 2019 / Kenji Rikitake 17
  15. Variable binding strategies between Erlang and Elixir differs with each

    other • Erlang: single binding only, with implicit pa8ern matching • Elixir: mul;ple binding allowed as default, pa8ern matching enforceable with the pin (^) operator #CodeBEAMSTO 2019 / Kenji Rikitake 18
  16. Erlang enforces single binding variables 1> A = 10. 10

    2> A = 20. ** exception error: no match of right hand side value 20 % Each variable can only be bound *once and only once* 3> B = [1, 2]. [1,2] 4> [_, X] = B, X. 2 % Bindings are equivalent to the pattern matching #CodeBEAMSTO 2019 / Kenji Rikitake 19
  17. Advantages of Erlang's single-binding variables • Debugging gets easier: once

    a variable is bound, it doesn't change un7l the func7on exits • The meaning a<ached to every variable must be clearly defined, because no shared meaning is allowed #CodeBEAMSTO 2019 / Kenji Rikitake 20
  18. Erlang's ambiguity on case expression (1) case an_expr() of %

    S is bound to an_expr()'s result {ok, S} -> do_when_matched(); _ -> do_when_unmatched() end #CodeBEAMSTO 2019 / Kenji Rikitake 21
  19. Erlang's ambiguity on case expression (2) S = something, %

    newly added case an_expr() of % an_expr()'s result is pattern-matched implicitly % to the result of previous S instead {ok, S} -> do_when_matched(); _ -> do_when_unmatched() end #CodeBEAMSTO 2019 / Kenji Rikitake 22
  20. Elixir allows variable rebinding 8 iex(1)> a = 10 10

    iex(2)> a = 20 20 # a is rebound # pin operator forces pattern matching without rebinding iex(3)> ^a = 40 ** (MatchError) no match of right hand side value: 40 8 Stack Overflow: What is the “pin” operator for, and are Elixir variables mutable? #CodeBEAMSTO 2019 / Kenji Rikitake 23
  21. Advantages of Elixir's mul5ple binding • Aligning well with the

    default behavior of many other languages • Pa8ern-matching is explicitly controllable to remove ambiguity, e.g. for case expressions #CodeBEAMSTO 2019 / Kenji Rikitake 24
  22. Elixir on case expression (1) s = :a_previous_value case an_expr()

    do # s is bound to an_expr()'s result anyway {:ok, s} -> do_when_matched() _ -> do_when_unmatched() end #CodeBEAMSTO 2019 / Kenji Rikitake 25
  23. Elixir on case expression (2) s = :a_previous_value case an_expr()

    do # an_expr()'s result is explicitly pattern-matched # with the content of s (:a_previous_value) # by the pin operator before s {:ok, ^s} -> do_when_matched() _ -> do_when_unmatched() end #CodeBEAMSTO 2019 / Kenji Rikitake 26
  24. Erlang's deep-copied variables 1> A = 10, B = [A,

    30]. [10,30] 2> f(A), A. % f(A): unbind A * 1: variable 'A' is unbound 3> B. [10,30] # old A remains in B #CodeBEAMSTO 2019 / Kenji Rikitake 27
  25. Elixir's deep-copied variables iex(1)> a = 10; b = [a,

    30] [10, 30] iex(2)> a = 20; [a, b] [20, [10, 30]] # old a remains in b #CodeBEAMSTO 2019 / Kenji Rikitake 28
  26. Advantage of deep-copied variables • Immutable, by always crea1ng new

    object bodies for copying • The same copy seman1cs is applied regardless of the data types, especially between simple (integers, atoms) and structured (lists, tuples, maps) types #CodeBEAMSTO 2019 / Kenji Rikitake 29
  27. Disadvantages of shared-nothing / deep- copied variables • Slow: all

    assignments imply deep copying • Much more memory space: you cannot implicitly share ... Are they really disadvantages at the age of abundant processing power and memory space? #CodeBEAMSTO 2019 / Kenji Rikitake 30
  28. Many of programming languages work in different ways as default

    Variables are not necessarily immutable Copy seman+cs differ between different data types #CodeBEAMSTO 2019 / Kenji Rikitake 31
  29. LISP is not necessarily immutable, even it's a func8onal language

    9 (defparameter *some-list* (list 'one 'two 'three 'four)) (rplaca *some-list* 'uno) (rplacd (last *some-list*) 'not-nil) ; result by CLISP 2.49 (ONE TWO THREE FOUR) ; original (UNO TWO THREE FOUR) ; head replaced (UNO TWO THREE FOUR . NOT-NIL) ; tail replaced 9 Source code example from Hyperspec Web site, modified by Kenji Rikitake, run on Wandbox with CLISP 2.49 #CodeBEAMSTO 2019 / Kenji Rikitake 32
  30. JavaScript has a complicated copy seman4cs // var a =

    {first: 1, second: 2} // b = a // only sharing *references* { first: 1, second: 2 } // a.second = 3 3 // b // changing a also changes b { first: 1, second: 3 } // b == { first: 1, second: 3 } false // WHY? // The right-hand side is a *constructor* #CodeBEAMSTO 2019 / Kenji Rikitake 33
  31. C# also has a complicated copy seman2cs Type int is

    value copied, List is reference copied (why??) using System.Collections.Generic; int i = 100; List<int> a = new List<int>(){10, 20}; MutableMethod(i, a); void MutableMethod(int i, List<int> a) { i = 200; a.Add(30); } Result: i = 100, a = {10, 20, 30} #CodeBEAMSTO 2019 / Kenji Rikitake 34
  32. C++: can you tell the difference? double func(std::vector<double> x); double

    func(std::vector<double> &v); // with reference double func(std::unique_ptr<std::vector<double>> u); double func(std::shared_ptr<std::vector<double>> s); std::vector<double> y = x; std::vector<double> &w = v; // with reference std::unique_ptr<std::vector<double>> u2 = std::move(u); // You cannot -> std::unique_ptr<std::vector<double>> u3 = u; ... actually, I'm not sure I can accurately explain the difference. #CodeBEAMSTO 2019 / Kenji Rikitake 35
  33. These languages perplex me by: 10 • Different ac,ons for

    different data types • Constructors (and destructors) • Copy seman,cs (C#: value type, reference type) • Shallow-copied objects = no immutability • Shared state and references as default 10 Rikitake, K.: Shared Nothing Secure Programming in Erlang/OTP, IEICE Technical Report IA2014-11/ICSS2014-11, Vol. 114, No. 70, pp. 55--60 (2014). (Slide PDF) #CodeBEAMSTO 2019 / Kenji Rikitake 36
  34. Design of these languages • Avoid object copying • Crea4on

    of objects need explicit ac4ons • Explicit use of reference • Object isola4on is the programmer's responsibility ... mostly for speed and cu2ng corners #CodeBEAMSTO 2019 / Kenji Rikitake 37
  35. What BEAM languages provide • Same ac(ons for all data

    types • No need for explicit constructors/destructors • Single copy seman(cs (deep copy) • Deep copied objects = immutability • No shared state, no reference, as default #CodeBEAMSTO 2019 / Kenji Rikitake 38
  36. Design of BEAM languages • Deep-copying as default • New

    objects are always created by assignments • Prohibit use of reference • Object isola=on is the language's responsibility ... for security first, and lagom speed second #CodeBEAMSTO 2019 / Kenji Rikitake 39
  37. The BEAM Programming Paradigm difference from the popularly-used shared-state object-oriented

    languages: Choice of default data copying mode By choosing lagom speed traded in for much more secure programming #CodeBEAMSTO 2019 / Kenji Rikitake 40
  38. Shared state .vs. distributed state: Which model is safer? Which

    model is more secure? Which model causes less bugs? #CodeBEAMSTO 2019 / Kenji Rikitake 42
  39. Topics excluded from this talk • BEAM architecture 11 •

    Concurrency models • Process supervision and signals • How BEAM languages handle shared states 11 Erik Stemman, The Beam Book #CodeBEAMSTO 2019 / Kenji Rikitake 43
  40. Acknowledgment This presenta,on is suppored by Pepabo R&D Ins,tute, GMO

    Pepabo, Inc. Thanks to Code BEAM Crew and Erlang Solu7ons! ... and thank you for being here! #CodeBEAMSTO 2019 / Kenji Rikitake 44
  41. Thanks, Joe. You taught me how to program in the

    principle of lagom är bäst. You helped me finding out a new hope for programming, a5er I got lost in the C header files of ISC BIND 9.4.2 in 2007. I'm impressed by your hospitality, as well as your crea6ve mind. We will remember you. #CodeBEAMSTO 2019 / Kenji Rikitake 45
  42. Photo / graphics credits • Title: Photo by Masayoshi Yamase

    on Unsplash • Lagom: Photo by Jen P. on Unsplash • Programming Erlang quote: from Pragma?c Bookshelf's EPUB ebook rendered by iBooks on macOS 10.14.4, underline added by Kenji Rikitake • Joe Armstrong: Photo by Brian L. Troutwine, edited by Kenji Rikitake, licensed CC BY-NC 4.0 Interna?onal • Pepabo R&D Ins?tute Logo: GMO Pepabo, Inc. • Thank you page: Photo by Raphael Andres on Unsplash • All the other photos: Kenji Rikitake #CodeBEAMSTO 2019 / Kenji Rikitake 47