[erlang-questions] Erlang and the learning curve

[Robert Raschke]

On Tue, Jan 4, 2011 at 11:31 AM, Morten Krogh <mk@REDACTED> wrote:

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

While I understand the sentiment, it is worth pointing out that premature
optimisation is a bad thing. Most (but not all) of the desire to control
memory and performance is completely unwarranted and is a waste of time and
leads to maintenance issues in the future and usually also negates any
performance work done at the OS or language level.


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

You usually do not have nice high-level data structures, pattern matching
and functions as first-class citizens. This leads to loads of code for
unpacking/accessing, checking and repacking of data. Combine this with
premature optimisation and you frightfully easily fall into the trap of
using global variables.


> 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?
>
>
If you write in a functional style in C (or Perl or Python or even C++) then
things are pretty much as you say. But Java, for example, makes this
unbelievably hard.


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

I recently attempted to understand the flow in a (real-life) Java program of
calculating one value (an SLA time calculation, this involves summing up
time spent on a task taking agreed time windows and holidays into account).
I waded through a total of 20 files to find bits of that calculation spread
across ten of them, the other ten were taking data apart or accessing things
like the holiday plan. And this even though it was possible to extract the
necessary numbers up front and then do the actually pretty simple
calculation based solely on those numbers.

My point is that while it is probably possible to write a similarly poorly
structured piece of code in a functional language, it would be much much
harder to do. This is because you do not have the luxury of simply stashing
some random value in the "global" space (I count inheritance as part of
global!) because you're going to need it in a completely different part of
your code later on.

A functional approach to programming changes the way you think about data
structures, data flow, and the operation you want/need to carry out on your
data. And this in turn makes it easier to come up with a simpler main
program flow.

The programming language you use does influence the way you think about
programming. Or maybe more accurately, the programming paradigms supported
by the language you use ....

Tuppence, etc.
Robby