New EEP draft: Pinning operator ^ in patterns

[Zsolt Laky]

Dear Erlang Friends,

I must admit at the first look I feel shocked about EEP-55 and felt what a number of fellows expressed here.

The e-mail storm forced (and some free time let) my mind to dig a little bit deeper, so I went through the EEP line by line, trying to understand what it can bring.

I see the value, also have concerns about parts that has not been covered there (comprehensions for example), anyway I tried to put myself in a different position and asked two questions:

1. In how many places this change will suggest me to use the operator? In other words, shall I refactor my code because of this?
IMHO as the feature is disabled by default. I will have nothing to do with old code and not forced to use ^ in my new code. I feel it as a helping hand that highlights ambiguity in the code. I am definitely not forced to use it, however I might be pushed to understand the syntax in case I read code written by others. When I went through the proposal as a learning curve, I felt pretty confortable with the new syntax.

2. If this pinning operator has already been in Erlang from the beginning, would I open an EEP to remove it? With this logic if list comprehensions were not part of the syntax and an EEP wanted to implement it, I can not imagine the storm that would be generated with its new way of simplifying list generations. And these switched the light on. It is just a matter of understanding what the EEP really is and getting used to a bit of additional syntax like it was with maps (and definitely not with list comprehensions just because they were already there). My answer would be for removing the pinning or list comprehensions is a definite: NO.

Regarding Elixir's ^ I see it as an operator in a different language. We have it in many, in Pascal for example defining a pointer type is like "IntPtr : ^pInt"; then using it like "pInt^" to access the value. In addition assigning a value to it is like "pInt := @number" when "var number: integer". What an inconsitent grammar! I can hardly follow it. So other language has other syntax and I shall not mix them. 

I think the biggest enemy of growth is the resistance to change. Even in everyday life. It does not mean I am with or against the proposal. It is just a thing to think about. I understand the pros and cons, challenge my mind about the matter, like if pinning operator could be used in function clauses for maps, how it helps in comprehension etc., but at the end what matter to me is to keep the constructive spirit, remain open for new things to consider and mind the communication culture. Otherwise our community will suffer.

I can live with or without the pinning operator (as we do not have it currently), in summary however, I feel it brings more value than it takes.

Let us talk about bringing things forward. Let us think about how could the open questions be solved instead of finding arguments why do not we need it.

If we fail solving the open questions, there is no sense to use it anyway.do not need it anyway.

Zsolt Laky

> On Jan 28, 2021, at 5:16 PM, Michael P. <empro2@REDACTED> wrote:
> 
> :-)
> 
> On Thu, 28 Jan 2021 13:30:50 +0100
> Raimo Niskanen <raimo+erlang-questions@REDACTED> wrote:
> 
>> Still I think that if e.g WhatsApp and Klarna left Erlang for something
>> else the Erlang community would be in a much worse position.
> 
> I wish they would replace it with Java,
> like Ericsson did ... tried .... >;>
> 
>> C2 "The more people contribute to a project,
>         the more its result approaches mediocrity."
> 
> I say, I say, I say
> 
> This is somehow associated with _D. Knuth_ in my brain,
> but I cannot trace it.
> 
> 
>> "forecefully"...
> 
> No. R. Carlsson appears single-minded, some might even say narrow-minded,
> but he analysised code and dug up examples -- far from "forcefully".
> 
> 
> ~M
> 
> --
> 
> Never attribute to malevolence or stupidity,
> what might be explained as a simple misunderstanding.
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210128/c1c0b444/attachment.htm>