<div dir="ltr">Interesting. Not so strictly speaking, some of the gen_server calls that do not change its state may be seen as 'pure' albeit relying on messaging, and a tool could probably figure out such calls automatically. And this definitely could help to figure out what' going on in a project.<img src="https://mltrk.io/pixel/jlfbezbj7JmxKgpSsPrd?rid=jlfbezbj7JmxKgpSsPrd" width="1" height="1" border="0"></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 12:12 PM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017年09月28日 木曜日 11:38:08 you wrote:<br>
> > No messaging, no external resource calls, no ets, no nifs, certain<br>
> functions in io and io_lib are out, etc.<br>
><br>
> So each function sending a message out is impure by definition, therefore<br>
> all gen_server calls are impure too. Meaning -pure declarations are<br>
> applicable only to a narrow subset of all functions defined. I just wonder<br>
> how many paths are in a graph of calls not involving calls to gen_server:*<br>
> family in a typical Erlang application.<br>
<br>
</span>Yep.<br>
<br>
What winds up being pure is your implementation of how you react to all<br>
those messages.<br>
<br>
If you write code with the deliberate intention of making as much of<br>
your code pure as possible you wind up with quite a few very happy side<br>
effects (no pun intended). You start building side-effecty message and<br>
IO bussing procedures that involve dispatch to implementation functions<br>
that do the actual work of processing your values -- and all of those<br>
become provable. This naturally separates transport from processing,<br>
and a set of useful outcomes within your own mind and your development<br>
team tend to result.<br>
<br>
I don't know how to go about quantifying those effects -- but doing things<br>
like onboarding new team members is markedly easier and the time between<br>
them showing up (perhaps not knowing Erlang) and contributing more than<br>
distractions to the effort is MUCH shorter.<br>
<br>
The bottom line is that passing stuff around is NOT the main job of your<br>
program in most cases, manging some problem of the real world usually is.<br>
Incident to that, you model the problem in two ways: the path and manner<br>
of how messages move around, and within processes how the values involved<br>
are processed. The value processing parts are sequential, procedural, and<br>
can be proven and made pure. The message passing is messy, unprovable,<br>
in a sense unreliable, subject to random timing, and a bunch of other<br>
effects that derive from the fact that the real world actually works that<br>
way, and these aspects make that half of any concurrent solution chaotic<br>
and unprovable.<br>
<br>
You'll get a lot more mileage out of a pure type graph in, say, a business<br>
data processing system (something like 80/20 pure/impure) than a chat or<br>
comment threading system (something more like 20/80). In simulation systems<br>
like game servers you get about 50/50 -- which is still a huge win because<br>
a lot of the processing involved is subtle and really needs to be property<br>
tested lest you invent some wacky emergent behaviors that players will<br>
exploit almost instantly as if by magic.<br>
<br>
These are tools to make better software and, most importantly, help us<br>
understand what we are actually trying to do. In this sort of inherently<br>
messy effort the perfect is absolutely the enemy of the good.<br>
<div class="HOEnZb"><div class="h5"><br>
-Craig<br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">With best regards,<div>     Roman Galeev,</div><div>     +420 702 817 968</div></div></div>
</div>