[erlang-questions] Trying to learn the Erlang Way

[kraythe .]

Well I am not a programming newbie. ;-) Just an erlang newbie. If I had a
dollar for every silly "is" mistake I have made, Id be rich. At any rate
thanks for the advice. I think naming is not necessarily a religious thing,
or it shouldn't be. It is very valid to adapt the standards of the source
language. Thats what annoys me when people write Java code like C code.

Anyway back to the subject at hand. The algorithm is set but now I am at
another quandary Lets say these vectors represent a position in space of
particular objects in a simulation. The process of culling the vectors
based on the sphere is entirely a vector problem but what the user calling
cull/3 really needs to know is which objects are not culled from the list,
not just which vectors are not culled. Now in Java I could do a number of
things if I wanted to keep the cull algorithm as it is. I could return the
list of integers containing the original indexes of the vectors in the list
that were culled and use that to filter out which objects need to be
considered for the simulation step. I.e:

List<Integer> survivors = cull(C, R, Candidates);
for(final Integer index : survivors) handleSurvivor(Candidates.get(index));

Now the question is what is the erlang way to do this?

Thanks in advance.

*Robert Simmons Jr. MSc.*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*


On Fri, Feb 7, 2014 at 9:35 AM, Garrett Smith <g@REDACTED> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140207/bfaacff8/attachment.htm>