<div dir="ltr">Thanks Fred for clarifying the example in your original response.  Thanks too to OK for the additional information, more below.<div><br></div><div>Cheers,</div><div>Rich<br><div class="gmail_extra"><br><span class="im" style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">On Mon, Mar 30, 2015 at 7:39 AM, Fred Hebert </span><span dir="ltr" style="font-size:12.8000001907349px"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span><span style="font-size:12.8000001907349px"> wrote:</span></span></div><div class="gmail_extra"><span class="im" style="font-size:12.8000001907349px">> On 03/31, Youngkin, Rich wrote:<br></span><blockquote class="gmail_quote" style="font-size:12.8000001907349px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im">   try<br>       {ok, Cs} = adventure:collect_coins(),<br>       Res = lists:flatmap(fun(Coins) -><br>           {ok, Val} = adventure:buy_treasure(Coins),<br>           Val<br>       end, Cs),<br>   of<br>       SuccessValue -><br>           %% Do something like continue to next challenge<br>   catch<br>       Type:Reason -><br>           %% Do something like maybe repeat the previous challenge<br>   end.<br></span>...<span class="im"><br>   try<br>       lists:flatmap(fun(Coins) -> adventure:buy_treasure(Coins) end,<br>                     adventure:collect_coins())<br>   of<br>       SuccessValue -> % Keep going<br>   catch<br>       _:_ -> % alt path<br>   end<br><br></span></blockquote><br><span class="im"><span style="font-size:12.8000001907349px">>> </span>I don't see a difference between the previous 2 Erlang implementations. Can<br><span style="font-size:12.8000001907349px">>> </span>you elaborate?<br><br></span></blockquote><br style="font-size:12.8000001907349px"><span style="color:rgb(80,0,80);font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">One of them matches on `{ok, Value}' to cause a failure, which makes the assumption 'bad' cases are returned </span></div><div class="gmail_extra"><span style="color:rgb(80,0,80);font-size:12.8000001907349px">></span><span style="color:rgb(80,0,80);font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">as</span><span style="color:rgb(80,0,80);font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">`undefined' or `{ok, Error}'. In the latter case it is expected that the called code raises exceptions when something </span></div><div class="gmail_extra"><span style="color:rgb(80,0,80);font-size:12.8000001907349px">></span><span style="color:rgb(80,0,80);font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">goes</span><span style="color:rgb(80,0,80);font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">wrong.</span></div><div class="gmail_extra"><span style="font-size:12.8000001907349px"><br></span></div><div class="gmail_extra"><span style="font-size:12.8000001907349px">Got it, thanks!</span></div><div class="gmail_extra"><span style="font-size:12.8000001907349px"><br></span></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 1, 2015 at 5:56 PM,  <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br></span>I find the Java example compelling:  if I want some threads<br>
communicating in a particular way in Java, as of 1.8 it is<br>
easier to go back to basics than to read all the library<br>
documentation and figure out what's going on.<br>
<br>
What saves the OTP behaviours from the same fate?<br>
Mainly the fact that there aren't very many of them,<br>
and the number isn't growing.  Erlang/OTP seems to strike<br>
a very nice balance between a core of simple Erlang<br>
primitives and a limited palette of "big" behaviours that<br>
take a lot of the work off your hands.  Futures fall into<br>
the "much needed gap".<br></blockquote><div><br></div><div>Interesting point. One of the things I like about Erlang is it's simplicity. I don't quite follow what you mean by "Futures fall into the "much needed gap"". Are you saying that futures should, or should not, be added to Erlang/OTP? I'm thinking not.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
When you might reach for a FutureTask<T> in Java, in<br>
Erlang you would think about what the processes are<br>
doing and how they communicate and you would look at the<br>
constellation of communicating processes and you might<br>
very well end up thinking that the Future-style<br>
communication pattern was *not* after all the best.<br>
<br>
<span></span></blockquote><div><br></div><div>Agreed. Understanding the problem and picking an appropriate solution is always the best approach. Blindly implementing a solution, either because you don't really understand the problem or because something is cool (e.g., futures), is never good.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> Garrett Smith gave a great presentation at last week's Erlang conference<br>
> about "The Timeless Way of Building Erlang Apps" (see [3] and<br>
> <a href="http://erlangpatterns.org" target="_blank">erlangpatterns.org</a>). What I think could be useful is a "pattern"<br>
> description for futures that incorporates the implementation using RPCs. I<br>
> may just do this if someone doesn't beat me to it.<br>
<br>
</span>For me, the single most important piece of advice is<br>
DON'T THINK IN TERMS OF FUTURES AND THEN ENCODE THAT IN ERLANG.<br>
Think in terms of processes and the communication between them.<br>
Consider alternative communication architectures.<br></blockquote><div><br></div><div>One of my motivations in starting this email thread is due to my relative newness to Erlang. As might be apparent from some of my questions, I don't necessarily have a good understanding of the best practices for solving a given class of problems. For someone like me it would be good to at least have code examples of how to implement certain best practices. These examples could also include information on what problems they might not be appropriate to for. Regarding futures, I'm assuming, perhaps mistakenly, that they could be useful in some Erlang applications. Regarding best practices, this is the area that I believe <a href="http://erlangpatterns.org" target="_blank">erlangpatterns.org</a> is intended to address. </div><div><br></div><div>To reiterate what I said above, one shouldn't blindly implement a solution without considering when it is appropriate and when it isn't appropriate. This is what I think you meant when you stated above "DON'T THINK IN TERMS OF FUTURES AND THEN ENCODE THAT IN ERLANG".</div><div><br></div></div></div></div></div>