RUBY IS FROM MARS, Functional Languages Are from Venus Integrating Ruby with Erlang, Scala & F# ANDREA O. K. WRIGHT Chariot Solutions [email protected] 1 The source for all of the examples can be found at: https://github.com/A-OK/RubyIsFromMars Conventions Used on These Slides Console sessions are generally represented with a black background. Console prompts and output are colored yellow. Text entered into the console is colored white, red or green. Red and green are used to highlight portions of entered code. Here is a sample irb session: > phrases = ["Ruby is from Mars", "Functional Languages are from Venus"] => ["Ruby is from Mars", "Functional Languages are from Venus"] > phrases.join(", ") => "Ruby is from Mars, Functional Languages are from Venus" 2 About the Sample Code on the Slides... Code examples on the slides don’t always show all the require or include statements needed in order for the code to run. For the complete code samples used in this presentation, as well as complete details about how they were run and which versions of projects were used: https://github.com/A-OK/RubyIsFromMars 3 4 The title of this talk is a reference to the classic book that asserts that men and women handle problems so differently, itʼs as if they come from different planets where different languages are spoken. But Iʼm not going to be talking about programming languages in terms of gender. I chose to link Ruby with Mars because Mars is the red planet. The book title has taken on a life of its own... 5 ...and is now used to refer to all manner of polar opposites. DEVELOPERS ARE FROM MARS, Ops People are from Venus ENGINEERS ARE FROM MARS, Marketers are from Venus CIOS ARE FROM MARS CEOs are from Venus 6 These are titles of blog posts about how people with vastly different approaches to solving problems could potentially work together well if they could just learn to communicate with each other. FUNCTIONAL IMPERATIVE 7 Functional and imperative programming are two vastly different approaches to solving problems. Functional programming is programming without side-effects. Itʼs programming with functions that you can count on to return the same thing whenever you pass in the same arguments because they donʼt depend on anything other than the arguments they are passed. Side-effect free functions donʼt need to access anything that is subject to change, like the filesystem, the GUI, mutable data structures or mutable variables -- and they likewise donʼt modify anything that exists outside of their function scopes. For this talk, Iʼm going to go ahead and define a functional language as a language thatʼs partial to functional programming. From Programming Erlang by Joe Armstrong Let’s see what can happen when you’re allowed to change a variable. 1> X = 23. Let’s define a variable X as follows: 23 8 Erlang meets that criteria. Hereʼs a passage about Erlangʼs view of mutable variables from Erlang creator Joe Armstrongʼs Programming Erlang book. He writes: “Letʼs see what can happen when youʼre allowed to change a variable,” -- and he shows a console session where X is bound to 23. From Programming Erlang by Joe Armstrong Let’s see what can happen when you’re allowed to change a variable. 1> X = 23. Let’s define a variable X as follows: 23 2> Y = 4 * X + 3. Now we can use X in computations: 95 9 He uses X in an equation... From Programming Erlang by Joe Armstrong Let’s see what can happen when you’re allowed to change a variable. 1> X = 23. Let’s define a variable X as follows: 23 2> Y = 4 * X + 3. Now we can use X in computations: 95 Now suppose we could change the value of X: 3> X = 19. (horrors) 10 ... and then writes: “Now suppose we could change the value of X (horrors)” The emphasis is mine, but he does actually use the word “horrors” in his text where he shows a console session with an attempt to set X to 19. From Programming Erlang by Joe Armstrong Let’s see what can happen when you’re allowed to change a variable. 1> X = 23. Let’s define a variable X as follows: 23 2> Y = 4 * X + 3. Now we can use X in computations: 95 Now suppose we could change the value of X: 3> X = 19. in process <0.31.0> with exit value: {{badmatch,19},[{erl_eval,expr, (horrors) 3}]} 11 And then he shows the error that appears in the console when you try to change the value of a bound variable. From Programming Erlang by Joe Armstrong Let’s see what can happen when you’re allowed to change a variable. 1> X = 23. Let’s define a variable X as follows: 23 2> Y = 4 * X + 3. Now we can use X in computations: 95 Now suppose we could change the value of X: 3> X = 19. in process <0.31.0> with exit value: {{badmatch,19},[{erl_eval,expr, (horrors) 3}]} But just suppose we could do this; then the value of Y would be wrong in the sense that we can no longer interpret statement 2 as an equation. 12 He collects himself and goes on to point out that the statement in line 2 could no longer be interpreted as an equation if the value of X was allowed to change. From Programming Erlang by Joe Armstrong Let’s see what can happen when you’re allowed to change a variable. 1> X = 23. Let’s define a variable X as follows: 23 2> Y = 4 * X + 3. Now we can use X in computations: 95 Now suppose we could change the value of X: 3> X = 19. in process <0.31.0> with exit value: {{badmatch,19}, (horrors) [{erl_eval,expr,3}]} But just suppose we could do this; then the value of Y would be wrong in the sense that we can no longer interpret statement 2 as an equation. 13 Notice that the error message says “bad match,” and not something like “Attempt to modify a non-modifiable values.” This is because in Erlang, the equals sign (=) is the pattern matching operator, not the assignment operator. The error is pointing out that 19 does not match 23. Joe Armstrong describes the variable definition statement in line 1 as pattern matching with a simple pattern, and not as variable assignment. He explains that if there are unbound variables on the left-hand side of an equation, the pattern matching operator will take care of the variable binding to make the pattern on its left-hand side match the pattern on its right-hand side. Equations and “=” in Erlang 1> 2 + 3 = 4 + 1 5 14 The concept of using the equals sign the way it would be used in a mathematical equation is very important in Erlang: in math the equals sign signifies that the left-hand side matches the right-hand side. Hereʼs a example that shows the extent to which Ruby and Erlang are not on the same page with respect to equals sign. Ruby would choke on a statement like the one in this slide, but itʼs perfectly valid in Erlang. Incidentally there are ways to mutate state in Erlang. For example, each process has a mutable process dictionary. But I think Erlangʼs functional bias is clear. Immutable vals scala> val x = 23 x: Int = 23 scala> x = 19 <console>:5: error: reassignment to val x=23 Mutable vars scala> var y = 23 y: Int = 23 scala> y = 19 y: Int = 19 15 Now letʼs look at why think Scala is partial to functional programming. This slide shows two ways to define variables in Scala. The val keyword is used to define immutable variables and the var keyword is for mutable variables. As you can see, changing the val, x, to 19 after initially setting it to 23, causes an error -- while there is no problem changing the value of the var, y. The vals are considered superior in the realm of Scala. In Scala , we should prefer using val over var as much as possible since that promotes immutability and functional style. ― Venkat Subramaniam, Programming Scala 16 In the Programming Scala, Venkat Subramaniam writes: “In Scala, we should prefer using val over var as much as possible since that promotes immutability and functional style.” Scala enables you to program imperatively, but as you get to know Scala better, you'll likely often find yourself programming in a more functional style. ― Bill Venners, Lex Spoon, Martin Odersky, “First Steps to Scala” 17 This sentiment is echoed in an article on the web called “First Steps to Scala” that was co-authored by Scala creator Martin Odersky: “Scala enables you to program imperatively, but as you get to know Scala better, you'll likely often find yourself programming in a more functional style.” F# Immutable Variables > let x = 23;; val it : int = 23 > x = 19;; val it : bool = false > x;; val it : int = 23 The mutable Keyword > let mutable y = 23;; val mutable y : int = 23 > y <- 19;; val it : unit = () > y;; val it : int = 19 18 In F#, variables are immutable by default. Although the F# console doesnʼt complain about the attempt to assign 19 to x after it was bound to 23, you can see that when x is evaluated in the console on the next line, it is still 23. To create mutable variables, you need to use the mutable keyword, and you have to use the special left arrow operator (<-) to modify their values.