[erlang-questions] Fwd: Must and May convention

[Roman Galeev]

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.

On Thu, Sep 28, 2017 at 12:12 PM, zxq9 <zxq9@REDACTED> wrote:

> On 2017年09月28日 木曜日 11:38:08 you wrote:
> > > No messaging, no external resource calls, no ets, no nifs, certain
> > functions in io and io_lib are out, etc.
> >
> > So each function sending a message out is impure by definition, therefore
> > all gen_server calls are impure too. Meaning -pure declarations are
> > applicable only to a narrow subset of all functions defined. I just
> wonder
> > how many paths are in a graph of calls not involving calls to
> gen_server:*
> > family in a typical Erlang application.
>
> Yep.
>
> What winds up being pure is your implementation of how you react to all
> those messages.
>
> If you write code with the deliberate intention of making as much of
> your code pure as possible you wind up with quite a few very happy side
> effects (no pun intended). You start building side-effecty message and
> IO bussing procedures that involve dispatch to implementation functions
> that do the actual work of processing your values -- and all of those
> become provable. This naturally separates transport from processing,
> and a set of useful outcomes within your own mind and your development
> team tend to result.
>
> I don't know how to go about quantifying those effects -- but doing things
> like onboarding new team members is markedly easier and the time between
> them showing up (perhaps not knowing Erlang) and contributing more than
> distractions to the effort is MUCH shorter.
>
> The bottom line is that passing stuff around is NOT the main job of your
> program in most cases, manging some problem of the real world usually is.
> Incident to that, you model the problem in two ways: the path and manner
> of how messages move around, and within processes how the values involved
> are processed. The value processing parts are sequential, procedural, and
> can be proven and made pure. The message passing is messy, unprovable,
> in a sense unreliable, subject to random timing, and a bunch of other
> effects that derive from the fact that the real world actually works that
> way, and these aspects make that half of any concurrent solution chaotic
> and unprovable.
>
> You'll get a lot more mileage out of a pure type graph in, say, a business
> data processing system (something like 80/20 pure/impure) than a chat or
> comment threading system (something more like 20/80). In simulation systems
> like game servers you get about 50/50 -- which is still a huge win because
> a lot of the processing involved is subtle and really needs to be property
> tested lest you invent some wacky emergent behaviors that players will
> exploit almost instantly as if by magic.
>
> These are tools to make better software and, most importantly, help us
> understand what we are actually trying to do. In this sort of inherently
> messy effort the perfect is absolutely the enemy of the good.
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 
With best regards,
     Roman Galeev,
     +420 702 817 968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170928/a72de756/attachment.htm>