[erlang-questions] Erlang and the learning curve

[Morten Krogh]

On 1/4/11 10:17 AM, Joe Armstrong wrote:
> No no no no no ..... Somehow you've gotten on the wrong foot here.
> Functional programming is *much* easier to understand than imperative
> programming.
>
Definitely not much easier. It depends on the problem, and whether you 
include
performance requirements. As soon as you want to control memory and 
performance,
functional languages can actually be much much harder. And I mean much 
harder.

Why are one fourth, or whatever, of the posts on this list about nif or 
c nodes or ports?

Even forgetting completely about performance, there are lots of problems 
that are more easily
solved and written using imperative techniques.

> 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.
>

You have pure functions in all languages, even if the type system 
doesn't force it on you.
I don't think it is such a big problem in C. You almost always 
understand whether a function has side effects or not.
Library functions rarely do, except for possibly changing pointer 
arguments, which is documented in the api.

But is Erlang so different here. I could write a sin function, that 
changed a file, say, during execution.
The issue is the same in C and Erlang. Library writers should not do it 
and mostly don't.
Do you feel this is a real problem in C?

What are the functions that are reused in Erlang but not in C?

> (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)
>

Are you talking about a loop?
Otherwise, a variable doesn't change that many times.
In Erlang, you would have recursive function invocations. The problem 
would then just be to
figure out in which invocation the error happened.
The debugging of this problem would be similar in C and Erlang, given 
that you use side effects.
A print statement in the loop or function is a side effect, which is 
very useful for this purpose.
Imagine a language (Haskell?), where you can't insert a print statement 
anywhere you want to for debugging purposes,
because the language is religious about avoiding side effects.
Even mutating a local variable can be valuable for debugging purposes.


> I really think that FPLs are an order of magnitude easier to
> understand than conventional PLs -
>
What? An order of magnitude?
Programming languages are actually still so similar, that the main flow 
of the program would
be the same no matter what language you use. Getting the data structures 
and data flow right is usually the same problem.
The syntax would then be somewhat shorter in Erlang than C or Java. But 
what about perl or python or ruby?
And most lines of code in C are easy to understand:

sum = 0;
for (i = 0; i < 1000000; i++) {
     sum += i;
}

It is longer than a one liner in a FPL, but it is effort less to write.

I think it is more correct to say that all languages have domains where 
they are strong and others where they are weak, but if
memory and performance really matters, you actually need languages that 
are closer to the hardware, and they are all imperative at the moment.

Cheers,

Morten.