Best practices -- conditional statements

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Best practices -- conditional statements

Donald Steven
The code excerpt below shows two alternate ways of branching. I'd be
grateful for opinions on which represents best practices. Thanks.


Don


makePanPositionL(Notes, Mode, L),

     CurrentPanPosition = hd(L),

     case Mode of

         left2right ->
             if
                 Notes < 6 -> PanPosition = CurrentPanPosition + 8;
                 Notes < 12 -> PanPosition = CurrentPanPosition + 4;
                 true -> PanPosition = CurrentPanPosition + 2
             end;

         left2right ->
             case Notes of
                 Few  when Few  < 6 -> PanPosition = CurrentPanPosition + 8;
                 More when More < 12 -> PanPosition = CurrentPanPosition
+ 4;
                 _Lots -> PanPosition = CurrentPanPosition + 2
             end;

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Ivan Uemlianin
This might be cheating but I would avoid the branching altogether if
poss., eg:

     PanPosition = CurrentPanPosition + notes_to_pad(Notes),
     ...

     notes_to_pad(N) where N <  6 -> 8;
     notes_to_pad(N) where N < 12 -> 4;
     notes_to_pad(_)              -> 2.

Also, I would avoid assignment inside a conditional, preferring eg:

     PanPosition =
         case Notes of
Few when Few < 6 -> CurrentPanPosition + 8;
             ...

Best wishes

Ivan


On 13/02/2019 12:40, Donald Steven wrote:

> The code excerpt below shows two alternate ways of branching. I'd be
> grateful for opinions on which represents best practices. Thanks.
>
>
> Don
>
>
> makePanPositionL(Notes, Mode, L),
>
>     CurrentPanPosition = hd(L),
>
>     case Mode of
>
>         left2right ->
>             if
>                 Notes < 6 -> PanPosition = CurrentPanPosition + 8;
>                 Notes < 12 -> PanPosition = CurrentPanPosition + 4;
>                 true -> PanPosition = CurrentPanPosition + 2
>             end;
>
>         left2right ->
>             case Notes of
>                 Few  when Few  < 6 -> PanPosition = CurrentPanPosition
> + 8;
>                 More when More < 12 -> PanPosition =
> CurrentPanPosition + 4;
>                 _Lots -> PanPosition = CurrentPanPosition + 2
>             end;
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

--
============================================================
Ivan A. Uemlianin PhD
Llaisdy

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                     [hidden email]
                         @llaisdy
                          llaisdy.wordpress.com
               github.com/llaisdy
                      www.linkedin.com/in/ivanuemlianin

                         festina lente
============================================================

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Jesper Louis Andersen-2
On Wed, Feb 13, 2019 at 1:51 PM Ivan Uemlianin <[hidden email]> wrote:
This might be cheating but I would avoid the branching altogether if
poss., eg:

     PanPosition = CurrentPanPosition + notes_to_pad(Notes),
     ...

     notes_to_pad(N) where N <  6 -> 8;
     notes_to_pad(N) where N < 12 -> 4;
     notes_to_pad(_)              -> 2.


makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6  -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_])                 -> Cur + 2.

You can just lift everything into a pattern match for this piece of code, which is what I think I'd do. It makes the result far more tabular, which in some cases is easier to read. There may be other reasons in the code to not do this, but as it was written, I think I'd pick the above as the solution. YMMV of course.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Donald Steven
In reply to this post by Ivan Uemlianin
Thanks!  I'm gonna try that.

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

makePanPositionL(Notes, Mode, L),

     mut CurrentPanPosition = hd(L),

     case Mode of
         left2right ->
             case Notes of
                 < 6   -> CurrentPanPosition += 8;
                 < 12  -> CurrentPanPosition += 4;
                 _else -> CurrentPanPosition += 2
             end;
         right2left ->
             ...

On 2/13/2019 7.51 AM, Ivan Uemlianin wrote:

> This might be cheating but I would avoid the branching altogether if
> poss., eg:
>
>     PanPosition = CurrentPanPosition + notes_to_pad(Notes),
>     ...
>
>     notes_to_pad(N) where N <  6 -> 8;
>     notes_to_pad(N) where N < 12 -> 4;
>     notes_to_pad(_)              -> 2.
>
> Also, I would avoid assignment inside a conditional, preferring eg:
>
>     PanPosition =
>         case Notes of
> Few when Few < 6 -> CurrentPanPosition + 8;
>             ...
>
> Best wishes
>
> Ivan
>
>
> On 13/02/2019 12:40, Donald Steven wrote:
>> The code excerpt below shows two alternate ways of branching. I'd be
>> grateful for opinions on which represents best practices. Thanks.
>>
>>
>> Don
>>
>>
>> makePanPositionL(Notes, Mode, L),
>>
>>     CurrentPanPosition = hd(L),
>>
>>     case Mode of
>>
>>         left2right ->
>>             if
>>                 Notes < 6 -> PanPosition = CurrentPanPosition + 8;
>>                 Notes < 12 -> PanPosition = CurrentPanPosition + 4;
>>                 true -> PanPosition = CurrentPanPosition + 2
>>             end;
>>
>>         left2right ->
>>             case Notes of
>>                 Few  when Few  < 6 -> PanPosition =
>> CurrentPanPosition + 8;
>>                 More when More < 12 -> PanPosition =
>> CurrentPanPosition + 4;
>>                 _Lots -> PanPosition = CurrentPanPosition + 2
>>             end;
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Ivan Uemlianin
Jesper's solution might be even better if you can handle that style. 
Your code base becomes more like a set of rules rather than procedures. 
You especially avoid the nested cases (which I didn't notice in your
first example).  Nested cases really seem to enforce a procedural view
of what's going on.

Ivan


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

> Thanks! I'm gonna try that.
>
> My multilingual (using elements of Rust and c), heretical fantasy
> (with apologies) is something like:
>
> makePanPositionL(Notes, Mode, L),
>
>     mut CurrentPanPosition = hd(L),
>
>     case Mode of
>         left2right ->
>             case Notes of
>                 < 6   -> CurrentPanPosition += 8;
>                 < 12  -> CurrentPanPosition += 4;
>                 _else -> CurrentPanPosition += 2
>             end;
>         right2left ->
>             ...
>
> On 2/13/2019 7.51 AM, Ivan Uemlianin wrote:
>> This might be cheating but I would avoid the branching altogether if
>> poss., eg:
>>
>>     PanPosition = CurrentPanPosition + notes_to_pad(Notes),
>>     ...
>>
>>     notes_to_pad(N) where N <  6 -> 8;
>>     notes_to_pad(N) where N < 12 -> 4;
>>     notes_to_pad(_)              -> 2.
>>
>> Also, I would avoid assignment inside a conditional, preferring eg:
>>
>>     PanPosition =
>>         case Notes of
>> Few when Few < 6 -> CurrentPanPosition + 8;
>>             ...
>>
>> Best wishes
>>
>> Ivan
>>
>>
>> On 13/02/2019 12:40, Donald Steven wrote:
>>> The code excerpt below shows two alternate ways of branching. I'd be
>>> grateful for opinions on which represents best practices. Thanks.
>>>
>>>
>>> Don
>>>
>>>
>>> makePanPositionL(Notes, Mode, L),
>>>
>>>     CurrentPanPosition = hd(L),
>>>
>>>     case Mode of
>>>
>>>         left2right ->
>>>             if
>>>                 Notes < 6 -> PanPosition = CurrentPanPosition + 8;
>>>                 Notes < 12 -> PanPosition = CurrentPanPosition + 4;
>>>                 true -> PanPosition = CurrentPanPosition + 2
>>>             end;
>>>
>>>         left2right ->
>>>             case Notes of
>>>                 Few  when Few  < 6 -> PanPosition =
>>> CurrentPanPosition + 8;
>>>                 More when More < 12 -> PanPosition =
>>> CurrentPanPosition + 4;
>>>                 _Lots -> PanPosition = CurrentPanPosition + 2
>>>             end;
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>

--
============================================================
Ivan A. Uemlianin PhD
Llaisdy

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                     [hidden email]
                         @llaisdy
                          llaisdy.wordpress.com
               github.com/llaisdy
                      www.linkedin.com/in/ivanuemlianin

                         festina lente
============================================================

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Donald Steven
In reply to this post by Jesper Louis Andersen-2
Alas, that creates a different form of code sprawl, as in:

makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6 -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_]) -> Cur + 2.
makePanPositionL(Notes, right2left, [Cur|_]) when Notes < 6 -> Cur - 8;
makePanPositionL(Notes, right2left, [Cur|_]) when Notes < 12 -> Cur - 4;
makePanPositionL(Notes, right2left, [Cur|_]) -> Cur - 2.
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) when Notes < 6 -> Cur + 16;
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) when Notes < 12 -> Cur + 8;
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) -> Cur + 4.
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) when Notes < 6 -> Cur - 16;
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) when Notes < 12 -> Cur - 8;
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) -> Cur - 4.


On 2/13/2019 8.35 AM, Jesper Louis Andersen wrote:
On Wed, Feb 13, 2019 at 1:51 PM Ivan Uemlianin <[hidden email]> wrote:
This might be cheating but I would avoid the branching altogether if
poss., eg:

     PanPosition = CurrentPanPosition + notes_to_pad(Notes),
     ...

     notes_to_pad(N) where N <  6 -> 8;
     notes_to_pad(N) where N < 12 -> 4;
     notes_to_pad(_)              -> 2.


makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6  -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_])                 -> Cur + 2.

You can just lift everything into a pattern match for this piece of code, which is what I think I'd do. It makes the result far more tabular, which in some cases is easier to read. There may be other reasons in the code to not do this, but as it was written, I think I'd pick the above as the solution. YMMV of course.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Ivan Uemlianin
Some people like it like that.  The repitition on the RHS makes me think there's room for more streamlining.

On 13/02/2019 15:02, Donald Steven wrote:
Alas, that creates a different form of code sprawl, as in:

makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6 -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_]) -> Cur + 2.
makePanPositionL(Notes, right2left, [Cur|_]) when Notes < 6 -> Cur - 8;
makePanPositionL(Notes, right2left, [Cur|_]) when Notes < 12 -> Cur - 4;
makePanPositionL(Notes, right2left, [Cur|_]) -> Cur - 2.
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) when Notes < 6 -> Cur + 16;
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) when Notes < 12 -> Cur + 8;
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) -> Cur + 4.
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) when Notes < 6 -> Cur - 16;
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) when Notes < 12 -> Cur - 8;
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) -> Cur - 4.


On 2/13/2019 8.35 AM, Jesper Louis Andersen wrote:
On Wed, Feb 13, 2019 at 1:51 PM Ivan Uemlianin <[hidden email]> wrote:
This might be cheating but I would avoid the branching altogether if
poss., eg:

     PanPosition = CurrentPanPosition + notes_to_pad(Notes),
     ...

     notes_to_pad(N) where N <  6 -> 8;
     notes_to_pad(N) where N < 12 -> 4;
     notes_to_pad(_)              -> 2.


makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6  -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_])                 -> Cur + 2.

You can just lift everything into a pattern match for this piece of code, which is what I think I'd do. It makes the result far more tabular, which in some cases is easier to read. There may be other reasons in the code to not do this, but as it was written, I think I'd pick the above as the solution. YMMV of course.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


-- 
============================================================
Ivan A. Uemlianin PhD
Llaisdy

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                    [hidden email]
                        @llaisdy
                         llaisdy.wordpress.com
              github.com/llaisdy
                     www.linkedin.com/in/ivanuemlianin

                        festina lente
============================================================ 

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Jesper Louis Andersen-2
You can remove some of that repetition as well:

notes(N) when N < 6  -> 8;
notes(N) when N < 12 -> 4;
notes(_N)            -> 2.

makePanPositionL(Notes, rapidlyleft2right, L) -> makePanPositionL(Notes, {rapidly, left2right}, L);
makePanPositionL(Notes, rapidlyright2left, L) -> makePanPositionL(Notes, {rapidly, right2left}, L);
makePanPositionL(Notes, {rapidly, Mode}, L)   -> 2 * makePanPositionL(Notes, Mode, L);
makePanPositionL(Notes, left2right, [Cur|_])  -> Cur + notes(Notes);
makePanPositionL(Notes, right2left, [Cur|_])  -> Cur - notes(Notes).

Though this is golfing, so go for the solution you think is most easy to read. One advantage of the above model is that it might be better if you are toying with altering the scaling. The scaling parameters are in one place in this code, so alteration is easier. Also, you can simplify by using an erlang term rather than an atom via the {rapidly, Mode} trick. Or perhaps just {scale, 2, Mode} and then interpret this as

mpp(Notes, {scale, K, Mode}, L) ->
  K * mpp(Notes, Mode, L).


On Wed, Feb 13, 2019 at 4:06 PM Ivan Uemlianin <[hidden email]> wrote:
Some people like it like that.  The repitition on the RHS makes me think there's room for more streamlining.

On 13/02/2019 15:02, Donald Steven wrote:
Alas, that creates a different form of code sprawl, as in:

makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6 -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_]) -> Cur + 2.
makePanPositionL(Notes, right2left, [Cur|_]) when Notes < 6 -> Cur - 8;
makePanPositionL(Notes, right2left, [Cur|_]) when Notes < 12 -> Cur - 4;
makePanPositionL(Notes, right2left, [Cur|_]) -> Cur - 2.
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) when Notes < 6 -> Cur + 16;
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) when Notes < 12 -> Cur + 8;
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) -> Cur + 4.
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) when Notes < 6 -> Cur - 16;
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) when Notes < 12 -> Cur - 8;
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) -> Cur - 4.


On 2/13/2019 8.35 AM, Jesper Louis Andersen wrote:
On Wed, Feb 13, 2019 at 1:51 PM Ivan Uemlianin <[hidden email]> wrote:
This might be cheating but I would avoid the branching altogether if
poss., eg:

     PanPosition = CurrentPanPosition + notes_to_pad(Notes),
     ...

     notes_to_pad(N) where N <  6 -> 8;
     notes_to_pad(N) where N < 12 -> 4;
     notes_to_pad(_)              -> 2.


makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6  -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_])                 -> Cur + 2.

You can just lift everything into a pattern match for this piece of code, which is what I think I'd do. It makes the result far more tabular, which in some cases is easier to read. There may be other reasons in the code to not do this, but as it was written, I think I'd pick the above as the solution. YMMV of course.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


-- 
============================================================
Ivan A. Uemlianin PhD
Llaisdy

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                    [hidden email]
                        @llaisdy
                         llaisdy.wordpress.com
              github.com/llaisdy
                     www.linkedin.com/in/ivanuemlianin

                        festina lente
============================================================ 


--
J.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Donald Steven
Aha!!!!!!!!!  Thanks Jesper and Ivan, much appreciated.

Don

On 2/13/2019 10.25 AM, Jesper Louis Andersen wrote:
You can remove some of that repetition as well:

notes(N) when N < 6  -> 8;
notes(N) when N < 12 -> 4;
notes(_N)            -> 2.

makePanPositionL(Notes, rapidlyleft2right, L) -> makePanPositionL(Notes, {rapidly, left2right}, L);
makePanPositionL(Notes, rapidlyright2left, L) -> makePanPositionL(Notes, {rapidly, right2left}, L);
makePanPositionL(Notes, {rapidly, Mode}, L)   -> 2 * makePanPositionL(Notes, Mode, L);
makePanPositionL(Notes, left2right, [Cur|_])  -> Cur + notes(Notes);
makePanPositionL(Notes, right2left, [Cur|_])  -> Cur - notes(Notes).

Though this is golfing, so go for the solution you think is most easy to read. One advantage of the above model is that it might be better if you are toying with altering the scaling. The scaling parameters are in one place in this code, so alteration is easier. Also, you can simplify by using an erlang term rather than an atom via the {rapidly, Mode} trick. Or perhaps just {scale, 2, Mode} and then interpret this as

mpp(Notes, {scale, K, Mode}, L) ->
  K * mpp(Notes, Mode, L).


On Wed, Feb 13, 2019 at 4:06 PM Ivan Uemlianin <[hidden email]> wrote:
Some people like it like that.  The repitition on the RHS makes me think there's room for more streamlining.

On 13/02/2019 15:02, Donald Steven wrote:
Alas, that creates a different form of code sprawl, as in:

makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6 -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_]) -> Cur + 2.
makePanPositionL(Notes, right2left, [Cur|_]) when Notes < 6 -> Cur - 8;
makePanPositionL(Notes, right2left, [Cur|_]) when Notes < 12 -> Cur - 4;
makePanPositionL(Notes, right2left, [Cur|_]) -> Cur - 2.
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) when Notes < 6 -> Cur + 16;
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) when Notes < 12 -> Cur + 8;
makePanPositionL(Notes, rapidlyleft2right, [Cur|_]) -> Cur + 4.
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) when Notes < 6 -> Cur - 16;
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) when Notes < 12 -> Cur - 8;
makePanPositionL(Notes, rapidlyright2left, [Cur|_]) -> Cur - 4.


On 2/13/2019 8.35 AM, Jesper Louis Andersen wrote:
On Wed, Feb 13, 2019 at 1:51 PM Ivan Uemlianin <[hidden email]> wrote:
This might be cheating but I would avoid the branching altogether if
poss., eg:

     PanPosition = CurrentPanPosition + notes_to_pad(Notes),
     ...

     notes_to_pad(N) where N <  6 -> 8;
     notes_to_pad(N) where N < 12 -> 4;
     notes_to_pad(_)              -> 2.


makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 6  -> Cur + 8;
makePanPositionL(Notes, left2right, [Cur|_]) when Notes < 12 -> Cur + 4;
makePanPositionL(Notes, left2right, [Cur|_])                 -> Cur + 2.

You can just lift everything into a pattern match for this piece of code, which is what I think I'd do. It makes the result far more tabular, which in some cases is easier to read. There may be other reasons in the code to not do this, but as it was written, I think I'd pick the above as the solution. YMMV of course.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


-- 
============================================================
Ivan A. Uemlianin PhD
Llaisdy

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                    [hidden email]
                        @llaisdy
                         llaisdy.wordpress.com
              github.com/llaisdy
                     www.linkedin.com/in/ivanuemlianin

                        festina lente
============================================================ 


--
J.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

empro2
In reply to this post by Ivan Uemlianin
On Wed, 13 Feb 2019 13:45:49 +0000
Ivan Uemlianin <[hidden email]> 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.









_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Best practices -- conditional statements

Ivan Uemlianin
Certainly code/language<->thinking is a vicious/virtuous circle. 
Interesting point about get & set.


On 13/02/2019 16:04, [hidden email] wrote:

> On Wed, 13 Feb 2019 13:45:49 +0000
> Ivan Uemlianin <[hidden email]> 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
>

--
============================================================
Ivan A. Uemlianin PhD
Llaisdy

Ymchwil a Datblygu Technoleg Lleferydd
Speech Technology Research and Development

                     [hidden email]
                         @llaisdy
                          llaisdy.wordpress.com
               github.com/llaisdy
                      www.linkedin.com/in/ivanuemlianin

                         festina lente
============================================================

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions