[erlang-questions] Erlang and the learning curve

[Henning Diedrich]

Hi Jack,

On Tue, Jan 4, 2011 at 9:52 AM, JETkoten<jetkoten@REDACTED>  wrote:

> ... just not getting it,  in terms of being able to do anything with Erlang in the real world.
>
> [snip]
>
> ... the gap  between understanding the basics and implementing real world projects

There's probably a difference between the big picture and learning
to think and program functional. And then, learning to code
in the first place.

Erlang's strengths would dictate were you want to use it for
in the real world. They may come from Erlang being functional.
But at least some strengths are unrelated, built into OTP.

Learning Erlang probably means "getting" different stuff then
"getting" what Erlang/OTP is good for.

And the learning isn't really going to be easier if you don't
have a strong coding background already, because most literature
will address you as someone coming from imperative languages
and needing to be re-educated. But still building on that in a way.
E.g. it's surprising how often you will run into Java on the way.
And, of course, C.
But you will probably *still* have to also unlearn some
stuff about coding, no matter how little exposure you had to
imperative languages before. if you are serious about coding,
it will be a most valuable experience I think.

> How

For me it was going for a project, reading, hacking, re-reading,
re-hacking. Reading samples and trying to adapt them on my way.
Spending some time, as Tran wrote.

The speed is way different from, say, using Ruby: some simple
things take way longer because you have to learn how it works,
language wise. but as Jesper said, it's a simple language. There
are some things that you may try that you find are not how it
works in Erlang at all. And then there are a lot of things that
are already ready made and you don't have to do anything
except learning to use them. So you may find you crawl where
it's a breeze with Ruby, and other things are a breeze in
Erlang/OTP where it's a pain in other ecosystems.

I read a lot of language comparisons to get an idea. And literally
let them lie and later read them again after some hacking.
I started out with the free first chapter of Armstrong's book.
I particularly liked http://learnyousomeerlang.com/, and also re-
read that a while later to fill gaps. I bought Armstrong's book relatively
late, only after having hacked a little, and I read and re-read ets
and dets, mnesia and supervisor stuff a couple of times.
I tried putting forth a benchmark that was interesting for me, too.

At the same time I started right into what I wanted to program,
and started from scratch again two times after understanding more,
based on samples from the web. I tried to define simple modules
and get them done, maybe not in perfect style, but working.

Plus reading the list, including archives on what looked strange,
and sometimes daring to get on somebodies nerves, helped a lot.

There are a handful of things that at a certain point "you get" and
then it 'starts to make sense.' I would dare say that if you
keep writing stuff and have some urge to produce nice code,
you will understand those things on your own. While you refactor
you realize why what makes sense and most likely it will take
a dozen iterations to get from your intuitively imperative approach
to something that looks functional. But if you do that a couple of
times, you'll do it right the first time after a while. I think it is
difficult to rush. It's also the mind bending fun of it.

In a way the things you can't do or will look ugly, guide you.
The stuff that looks pretty wrong, even though it works, if
you try to make it look right you will often see that it unravels
your whole approach and if you follow that through, and allow
that to happen you end up rewriting it all until your source
looks right (i.e. does not do stuff that is more imperative than
appropriate, not repetitive, hard to follow etc.) and on the
way you learn what functional element replaces what imperative
one. Like in OO polymorphic late binding replacing cases
over types.

Then tackle OTP, that's really a lot of vocabulary to learn and
procedure. The least attractive part for me and still essential
for productivity [1]. OTP is really inseparable from Erlang in a way.
You can't do certain things the Erlang way and skip that. But
that's quite separate from understanding functional
programming.

Since Erlang/OTP is not only functional, it's also enormously
practical, plus other things that don't have too much to do with
functionality really. Maybe they all come from that, in a way, but
there is also a very strong desire to get things done visible in
Erlang's DNA, and more so, in OTP.

I'd look at Yaws [2], Erlyweb [3] and MochiWeb [4] for your stuff
and start from there. I DONT'T think it's necessarily NOT a good
fit for Erlang, see the time sheet service BeeBole[5]. Take [6] as
inspiration ...  and Chicago Boss [7] is something that I don't
know about but saw mentioned on the list - and at least they
claim to be the future of the web, so --- maybe the package is
still small enough you could learn tons looking at their code.

Have fun,
Henning

[1] 
http://erlware.blogspot.com/2010/02/create-erlang-mochiweb-web-application.html
[2] http://yaws.hyber.org/
[3] http://erlyweb.org/
[4] https://github.com/mochi/mochiweb
[5] http://beebole.com/en/blog/erlang/why-erlang/
[6] 
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1/
[7] http://www.chicagoboss.org/index.html