[erlang-questions] Erlang and the learning curve

[Joe Armstrong]

On Tue, Jan 4, 2011 at 2:52 AM, JETkoten <jetkoten@REDACTED> wrote:
> Hi All,
>
> I've been reading/watching everything I can find (off and online) for
> learning Erlang for the past two or three weeks, but am just not getting it,
> in terms of being able to do anything with Erlang in the real world.
>
> I've watched some videos about functional programming where the hosts joked
> about people looking into functional programming deciding it's too hard and
> then never touching it again...

No no no no no ..... Somehow you've gotten on the wrong foot here.
Functional programming is *much* easier to understand than imperative
programming.

There is a sense in which *all* programming languages are difficult to
understand,
this is the phase where you are not familiar with the syntax and what
the various construct mean.

Take "C" for example - this is the Lingua Franca of all programming
languages - we all know C.
So let's do an experiment. Stop a C programmer in the corridor and ask
them the difference between:

    int *p[10];         and
    int (*p)[10];

One is "a pointer to (an array of 10 integers)" the other is "an array
of (ten pointers to integers)"

Then ask them what

    char * const *(*next)(); means

(next is a pointer to a function returning a pointer to a constant
pointer to a char")

A C program is actually extrememly difficult to understand - the above
problem is purely syntactic,
then the problem of understanding a C program is much deeper - you
have to mentally execute the
program in your head to understand what it means - this is due to side effects.

Functional programs are really really easy to understand, since given
that you understand what the inputs to a function are the fucntion
will always, always always, forever and ever and ever return the same
value.
This make the code extremely reusable.

if you are not familiar with the erlang syntax your eyes will not see
what my eyes see.

When I see code I mentally scan for the use of variables, I look for
the first occurrence and subsequent
occurrences. Imagine some function foo, that uses a variable X, when I
look for the uses
of X in foo my brain "sees" this:

      foo(....) ->
           ...
           X = ....                       <--- 1
           ...
           ...  bar(...X...) ...         <--- 2

           {...,...,X,....} = .....       <--- 3


I now know that X is defined at point 1 in the program. That it is
used in point 2
and that in point 3 that whatever is on the right hand side of the
equals in line 3 must return
a tuple whose 3'rd argument must be X

The fact that X never changes once it is set make the program
extremely easy to understand, and
debug. If a value is incorrect, it can only set in one place. You just
peer at the program, you don't need a debugger.

(in C for example, a value once set, might be changed a trillion
times, and one one occasion when
it is changed it gets the wrong value, but which of these times was
it? - this is *extremely* difficult
to understand, and a debugger might help)

I really think that FPLs are an order of magnitude easier to
understand than conventional PLs -

(don't get me started on languages like java - is Java easy compared
to erlang? - try writing the simplest
of callback functions in java and tell me java is easy to understand -
what's the visitor pattern like in java?

read

http://en.wikipedia.org/wiki/Visitor_pattern
then read the comment about the "Visitor Pattern in a Dynamic
programming language" as the wikipedia says:

"The visitor pattern disappears completely. No extra classes and
methods are needed"

)


> but seriously, how do people bridge the gap
> between understanding the basics and implementing real world projects with
> Erlang? I know the three major books are available, but none of them are
> really using Erlang for what I'd like to do...

This is what you do - buy one of the books - modestly prevents me from
telling you which is best -
then type in the programs staring at the simplest.

It's very important that you type in the programs *yourself* - don't
download the code
and run it.

You have to get the syntax into your spine not your brain.

When you type in the programs, you'll make tiny errors, missing commas etc.
Fix these error - this is the tricky bit.

Every programming language under the sun produces totally bizarre error message
when you get the punctuation wrong.

(aside

Image you're new to C and write this

int add(int a; int b){
  return a+b;
}

gcc says

test3.c:1: error: parameter ‘a’ has just a forward declaration
test3.c: In function ‘add’:
test3.c:2: error: ‘a’ undeclared (first use in this function)

Which is it's helpful way of saying - "sorry Joe it should be a comma in the
function arguments not a semicolon"
)

all error messages are difficult to understand.

The purpose of a book is to present you with small completely understandable
self-contained examples that you can type in and learn from.

It takes a few months to become fluent in any programming language -
reckon a couple of weeks for the syntax - then a few months before you
know your way around the libraries

/Joe







>
> How have any of you who have come to know big-picture how great Erlang is
> been able to get enough knowledge of it to actually do what you'd like to
> do?
>
> Any and all replies are most welcome.
>
> Thanks,
> Jack
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>