[erlang-questions] Design patterns?

Sean Cribbs sean@REDACTED
Wed Mar 4 16:06:20 CET 2015

I think the other argument for more functions over case expressions, which
Garrett Smith has given quite convincingly in a number of media [1] [2], is
that by naming things, you communicate meaning and increase clarity. Maybe
the code gets "longer", but each component has a very specific purpose that
is more obvious.

I've found lately -- and apologies to my coworkers who have to suffer code
reviews from me -- that like Ulf shows, I eschew anonymous functions except
when they are only one expression inside the fun, or simply call some other
function while capturing the environment. Another thing I've been finding a
distaste for is manual recursion over lists, where the same algorithm could
be expressed more simply with one of the HOFs in the lists module. I feel
using the lists module increases clarity for the next person to read the
code, and naming the per-item function does the same.

If you are wondering about design patterns around concurrency, obviously
OTP provides a lot of those, but there are some others that aren't part of
the distribution. I'd suggest checking out Jay Nelson's epocxy [3] and
gen_stream [4], Garrett's e2 [5], and of course the classics like
gen_leader [6], riak_core [7] and various process pools [8] [9].

[2] https://www.youtube.com/watch?v=CQyt9Vlkbis
[3] https://github.com/duomark/epocxy
[4] https://github.com/duomark/gen_stream
[5] http://e2project.org/
[6] https://github.com/KirinDave/gen_leader_revival
[7] https://github.com/basho/riak_core
[8] https://github.com/devinus/poolboy
[9] https://github.com/seth/pooler

On Wed, Mar 4, 2015 at 4:49 AM, Ulf Wiger <ulf@REDACTED> wrote:

> On 02 Mar 2015, at 20:20, Judson Lester <nyarly@REDACTED> wrote:
> And an open question (for me): when to use case/if versus function heads?
> Roughly, I've been using cases to reformat the returns of a function call,
> but the decision trips me up every time.
> There is a consideration worth noting that can affect this decision:
> While you can’t trace on a given case expression, you *can* trace a
> function call.
> In general, I very much agree with Richard O’Keefe: you should choose
> whatever best communicates your intent.
> However, and perhaps Anders Svensson (now on the OTP team) is one of the
> most extreme proponents of this view, breaking out things like local funs
> into separate functions, makes it much easier to debug. This is especially
> true in live real-time systems, where tracing is one of the few ways you
> *can* debug (hopefully) without making a mess of things.
> Now, Erlang does allow you to selectively trace on anonymous funs, in part
> since it translates them into actual functions using a consistent naming
> scheme, but only the nerdiest of Erlang programmers have actually memorized
> this scheme. So if the code looks like this (example from OTP’s ‘diameter’
> application):
> merge_service(Opts, Svc) ->
>     lists:foldl(fun ms/2, Svc, Opts).
> ms({applications, As}, #diameter_service{applications = Apps} = S)
>   when is_list(As) ->
> insert_local_peer(SApps, T, LDict) ->
>     lists:foldl(fun(A,D) -> ilp(A, T, D) end, LDict, SApps).
> ilp({Id, Alias}, {TC, SA}, LDict) ->
> - then you have no problems tracing the ‘inner loop’ function of e.g. a
> fold.
> (Note that in the second example, Anders uses an anonymous fun to include
> part of the environment.)
> From an aesthetic (i.e. communication) standpoint, I find it slightly
> unfortunate, but OTOH, when it’s consistently and competently done, I will
> agree that you reasonably quickly get used to ‘decoding’ the style.
> For those who want to judge whether it’s a technique they want to adopt, I
> recommend reading the diameter sources, where it *is* pretty consistently
> applied.
> BR,
> Ulf
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

Sean Cribbs <sean@REDACTED>
Sr. Software Engineer
Basho Technologies, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150304/bf74e21f/attachment.htm>

More information about the erlang-questions mailing list