[erlang-questions] Best practices -- conditional statements

[empro2@REDACTED]

On Wed, 13 Feb 2019 13:45:49 +0000
Ivan Uemlianin <ivan@REDACTED> wrote:

> example).  Nested cases really seem to enforce a
> procedural view of what's going on.

Is it not the other way around:

> On 13/02/2019 13:35, Donald Steven wrote:

> > My multilingual (using elements of Rust and c),
> > heretical fantasy (with apologies) is something like:

the procedural thinking causing the nesting and
distracting from, even preventing the calculation of values?

> > makePanPositionL(Notes, Mode, L),

Why "make" it and not calculate pan_position(...)?
Just as it is simply math:pi/0, not math:make_pi, get_pi,
approximate_pi, .../0

I am still "forgetting" the "naming conventions" of
procedural code - and that includes the "hidden procedures"
of object orientation. I even avoid the Smalltalk instead
of Algol identifiers (especially as fonts tend to have
short capitals (MlKkWf0Od) that are good for all-capital
words in writing but do not really stand out enough for
noInterWordSpaceWordSeparation).

In the last few years more and more Smalltalk identifiers
appeared in the docs (and the code), and though I am most
certainly a worse programmer (in general, not Erlang alone)
than anyone who has contributed to Erlang I would have
s/maps:get/maps:value/
(or maps:val, or in that context perhaps even maps:v)
and probably s/maps:new/maps:empty/, to solely describe an
empty map and avoiding the hint at the making of a new one.

I am hoping the value description instead of action
description helps me switch from procedural and OO to more
functional thinking.

The "branching" in the original post immediately made me
think of branching mnemonics (BCS, BCC, ...)

My! am I old :-)

Michael

-- 

Normality is merely a question of quantity,
not of quality.