<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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].</div><div><br></div><div>[1] <a href="http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html">http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html</a></div><div>[2] <a href="https://www.youtube.com/watch?v=CQyt9Vlkbis">https://www.youtube.com/watch?v=CQyt9Vlkbis</a><br>[3] <a href="https://github.com/duomark/epocxy">https://github.com/duomark/epocxy</a></div><div>[4] <a href="https://github.com/duomark/gen_stream">https://github.com/duomark/gen_stream</a></div><div>[5] <a href="http://e2project.org/">http://e2project.org/</a></div><div>[6] <a href="https://github.com/KirinDave/gen_leader_revival">https://github.com/KirinDave/gen_leader_revival</a></div><div>[7] <a href="https://github.com/basho/riak_core">https://github.com/basho/riak_core</a></div><div>[8] <a href="https://github.com/devinus/poolboy">https://github.com/devinus/poolboy</a></div><div>[9] <a href="https://github.com/seth/pooler">https://github.com/seth/pooler</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 4:49 AM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On 02 Mar 2015, at 20:20, Judson Lester <<a href="mailto:nyarly@gmail.com" target="_blank">nyarly@gmail.com</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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.</div></div></blockquote><br></div></span><div>There is a consideration worth noting that can affect this decision:</div><div><br></div><div>While you can’t trace on a given case expression, you *can* trace a function call.</div><div><br></div><div>In general, I very much agree with Richard O’Keefe: you should choose whatever best communicates your intent.</div><div><br></div><div>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.</div><div><br></div><div>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):</div><div><br></div><div>merge_service(Opts, Svc) -><br> lists:foldl(fun ms/2, Svc, Opts).<br><br>ms({applications, As}, #diameter_service{applications = Apps} = S)<br> when is_list(As) -><br><br></div><div>…</div><div><br></div><div>insert_local_peer(SApps, T, LDict) -><br> lists:foldl(fun(A,D) -> ilp(A, T, D) end, LDict, SApps).<br><br>ilp({Id, Alias}, {TC, SA}, LDict) -><br> …</div><div><br></div><div>- then you have no problems tracing the ‘inner loop’ function of e.g. a fold.</div><div><br></div><div>(Note that in the second example, Anders uses an anonymous fun to include part of the environment.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>BR,</div><div>Ulf</div><div><br></div><div>
<span style="border-collapse:separate;border-spacing:0px"><div><div>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.</div><div><a href="http://feuerlabs.com" target="_blank">http://feuerlabs.com</a></div></div><div><br></div></span><br>
</div>
<br></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Sean Cribbs <<a href="mailto:sean@basho.com" target="_blank">sean@basho.com</a>><br>Sr. Software Engineer<br>Basho Technologies, Inc.<br><a href="http://basho.com/" target="_blank">http://basho.com/</a></div>
</div>