[erlang-questions] Trying to learn the Erlang Way

[Garrett Smith]

On Fri, Feb 7, 2014 at 8:47 AM, kraythe . <kraythe@REDACTED> wrote:
> Man I feel silly. but then I am fighting a chest cold. I guess this happens
> easier when you don't have completion or highlighting that I am used to in
> an IDE.

Viva Eclipse!

But seriously, every programmer knows the feeling of at once being
certain something's wrong with the compiler/VM and then realizing the
obviousness of his or her mistake. You'll pick up quickly where to
look for the common sources of these.

Fred's comments on function naming are spot on - lower camel case is
almost never ever seen in Erlang and really stands out in a bad and
distracting way. I know this sounds religious, and it is, but it's the
True Religion, so it's fine.

Having very, very focused functions helps a lot both in writing a
program (it forces the programmer to make things obvious in code,
which is very hard to do but an excellent way to prove you understand
exactly what problems you're solving) and to debug a program (it's
hard for problems to lurk in obvious code).

This blog post says what I mean:

http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html

It's also True Religion, so it's fine. [1]

In cases where you really need to step through code (I think these are
rare, especially if you follow the obviousness rule) the function
tracing tools in Erlang are fantastic. Reid Draper happened to have
just presented a great tracing tool called redbug at the Chicago
Erlang User Group this Wednesday:

https://github.com/massemanet/eper/blob/master/src/redbug.erl

I've historically used e2's e2_debug module:

https://github.com/gar1t/e2/blob/master/src/e2_debug.erl

I'll might switch to redbug because it stops tracing automatically
after a period of time or number of traces, which is super great for
use in production systems. e2_debug is fine for local dev however --
and it's output is IMO much easier to read.

While you can use the Erlang visual debugger to step through code, I
personally find this time consuming and awkward and prefer to trace.
Problems in Erlang often come down to unexpected patterns that sneak
into a call chain, which are easy to spot through tracing.

Best of luck!

Garrett

[1] There is one stylistic change that I would recommend, vis-a-vis
that blog post, which is to *selectively* use variables to pull
important, side effecty operations out of nested function calls so
that they appear earlier in the function (western style top-down,
left-right reading) and get named results (via variable binding). So,
e.g.

    do_something_next(do_something_first())

Becomes:

   FirstResult = do_something_first()
   do_something_next(FirstResult)

God names are essential - these are terrible names, but you get the idea.

Do this only when it makes the code more obvious.

Richard O'Keefe pointed this out to me originally and, of course, he's right.