[socal-piggies] Fwd: Erlang slides

[Grig Gheorghiu]

I haven't had time to write the meeting minutes yet, so here are
Daniel's slides for your perusal in the mean time.

Grig

--- Daniel Arbuckle <djarb at highenergymagic.org> wrote:

> Date: Fri, 14 Jul 2006 09:17:32 -0700
> From: "Daniel Arbuckle" <djarb at highenergymagic.org>
> To: grig at gheorghiu.net
> Subject: Erlang slides
> 
> Here's the S5 slideshow
> 
---------------------------------
Erlang for Python programmers




SoCal Piggies, July 13 2006Erlang for Python programmers


Erlang for Python programmersDaniel ArbuckleSoCal Piggies
What is Erlang?
   A language designed by Ericsson Computer Science Laboratory (yes,
the telephone company)
   Designed from the get-go for concurrency programming
   Scalable from simple concurrency to distributed execution
   Functional (but that might not mean what you think)
[any material that should appear in print but not on the slide]

Digression: Functional Programming
   "Functional" doesn't mean "it works." Functional means "like a
mathematical function."
   In math, a function takes one or more inputs and produces a single
output (mathematicians, please don't kill me).
   The same is true in Erlang. Functions transform one or more inputs
into an output, and that's all they do.
   That has some implications that may not be immediately obvious to
you:	 	 
      Functions can't have side-effects, so you can't set state
variables	 
      In fact, variables can only be set once in a namespace; you can't
reassign them new values	 
      Functions don't care about their context, so code is very
re-usable	 

   Side-effects are allowed when they take place outside the 'universe'
of the program: this allows I/O routines.
   Functional Programming is strongly advocated here:
http://www.math.chalmers.se/~rjmh/Papers/whyfp.pdf
[any material that should appear in print but not on the slide]

Why would we want that?
   The mathematical approach can help keep concurrent programs sane,
and cut down on 'emergent properties' of the software
   Not being able to modify variables makes local concurrency much more
efficient; this benefit applies doubly to distributed concurrency
   There's a beauty to it that's rewarding in itself
   . . . after your head has finished exploding
[any material that should appear in print but not on the slide]

Digression complete
   Now we're going to look at how to do some fundamental things in
Erlang:
   Loops
   Branching
   Message passing
   Error handling
[any material that should appear in print but not on the slide]

Loops in Erlang and PythonWhere a Python programmer would type:an
Erlang programmer would type:
def foo(i):    for x in range(i, 11):        do_something(x)

foo(10) ->    do_something(0).foo(I) when I     do_something(I),   
foo(I + 1).

   In both cases, do_something is invoked (10 - i + 1) times
   Recursion is used in Erlang because it's the only way to write code
that refers to a variable whose value actually varies over time
(technically, it's a different variable with each invocation)
   When the last expression in a function is a recursive call to the
same function (a "tail recursion"), Erlang optimizes that expression
into a loop in the generated code. It's a recursion only in concept.
   Capitol I is used for the variable name because all variables names
must start with capitol letters. Words starting with a lowercase letter
are atoms (basically, a string without quotes). 
[any material that should appear in print but not on the slide]

Branching in Erlang and PythonWhere a Python programmer would type:an
Erlang programmer would type:or:
def foo(i):    if i == 10:        do_something(i)    elif i 
foo(10) ->    do_something(0).foo(I) when I     do_something(I),   
foo(I + 1).

foo(I) ->    if        I == 10 ->            do_something(I);        I 
           do_something(I),            foo(I + 1)    end.

   On the previous slide, I glossed over the foo(10) and when I . These
are the two primary ways of implementing branching in Erlang.
   All of the functions with the same name and the same number of
parameters ("arity") are implicitly wrapped into a single function and
a sequence of if/elif blocks.
   A parameter matches when it is either an unbound variable, or when
it is equal to the passed value. When all of the parameters match and
the 'when' clause, if any, is true, that version of the function is
executed.
[any material that should appear in print but not on the slide]

Message passing in Erlang and PythonWhere a Python programmer would
type:an Erlang programmer would type:
sock.sendall(pickle.dumps(('hello', 19, x)))f = sock.makefile('r')word,
number, x = pickle.load(f)f.close()if word == 'welcome':   
process(word, number, x)else:    error(word, number x)

Proc_id ! {hello, 19, X}.receive    {welcome, Number, Y} ->       
process(welcome, Number, Y);    {Word, Number, Y} ->        error(Word,
Number, Y)end.

   These examples aren't totally equivalent. Each time a receive block
executes, it finds the first message in the message queue that matches
one of its clauses, instead of just considering the first message.
   Erlang matches receive clauses in the same way that it does function
parameters.
   A receive block will block until a message it understands enters the
queue
   Nonlinear message delivery does a lot to decouple Erlang processes
from each other
[any material that should appear in print but not on the slide]

Error handling in Erlang and PythonWhere a Python programmer would
type:an Erlang programmer would type:
try:    something()except ByTheGodsNooo:    recover()

process_flag(trap_exit, true),Risky = spawn(thismodule, something,
[]),link(Risky),receive    {'EXIT', Risky, byTheGodsNoo} ->       
recover();    {'EXIT', Risky, Reason} ->        exit(Reason)end.

   In Erlang, you spawn off a new process to do anything risky. If the
process terminates normally, you know it worked.
   This creates a relationship between processes similar to the Python
call stack, allowing errors to propogate until something can handle
them.
   If the trap_exit process flag is unset, the calling process would be
automatically terminated, just as unhandled exceptions terminate
execution of a function in Python.
[any material that should appear in print but not on the slide]

Other tidbits
   Erlang has a match operator '='. It performs a function fairly
similar to function parameter matching. For example {A, {B, 10}} =
something() would bind A and B to the values in the equivalent
positions in the return value of something(), so long as the 10 matched
the value in the equivalent position.
   Erlang's per-process and process switching overheads are extremely
low.
   Erlang is freely downloadable from http://www.erlang.org/
   Erlang's concurrency model is very similar to C. A. R. Hoare's
mathematical theory of Communicating Sequential Processes:
http://www.usingcsp.com/
   Erlang has a fully capable macro facility, which can be used to
define new semantics.
[any material that should appear in print but not on the slide]

[slide title]
   [point one]
   [point two]
   [point three]
   [point four]
   [point five]
[any material that should appear in print but not on the slide]

-->

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/socal-piggies/attachments/20060714/83c5675b/attachment.html>