New EEP draft: Pinning operator ^ in patterns

[Karl Nilsson]

So I took the pinning branch for a spin and ran it against the Ra library (
https://github.com/rabbitmq/ra/pull/209) I have worked a lot on the last
few years. I found 2 bugs and at least a couple of places where I am not
really sure about the intent of the match and where it could be done
better. At some point I will run it against the RabbitMQ code. Who knows
what I will find there!
So thank you Richard, I take my hat (pun intended) off to you for this
feature and for standing up for it against the onslaught of negativity
around it. For me this feature, ad-hoc or not, addresses a real problem and
will result in fewer bugs which makes me prepared to deal with any
syntactic overhead it may carry.

I'd like to also address the often mentioned idea that functions should be
"small" (whatever constitutes small) as if that is some kind panacea for
writing good code. It is not. Quite the opposite. Arbitrarily small, local,
single-use functions can make code almost impossible to read and reason
about. This is especially the case in a dynamic language where you can't
even rely on editor type hints to work out what the function accepts as
input and returns as output and then possibly derive roughly what the
function does. Instead you have an indirection where you have to skip to
some other location in the file whilst trying to maintain the context of
where the function was called. This indirection makes reading/context
building very hard and IMO the most important feature of successful code
(code that remains in use) is that it can be read and understood with
minimal bother.

Just my 2 öre though...

On Fri, 22 Jan 2021 at 10:32, Nicolas Martyanoff <khaelin@REDACTED> wrote:

> On 2021-01-22 11:02, Raimo Niskanen wrote:
> > I am trying again, in hopefully a more civilized manner...
> >
> > By constantly repeating that your opinion would not matter and that
> someone
> > has a plan to force this feature through you indirectly say:
> > *) That the decision process for an EEP and the Technical Board at
> Erlang/OTP
> >    at Ericsson can not be trusted to make a good decision for the Erlang
> >    language and the community.
> > *) That the community does not want this feature.
> >
> > This is attacking the decision process itself instead of contributing to
> > the decision.  To me this feels like a way to force your point of view
> > through in this decision.
>
> Try to put yourself in the shoes of those who reject the proposal:
>
> - From the beginning, we are being told repeatedly that our answers do not
>   address the right part of the proposal, or are not valid arguments, or
> are
>   not the right way to argue. The last evolution of the debate is a
> comparison
>   to Trump...
>
> - As I already asked, for all these messages we still have not received any
>   information about who has real authority on this type of change to the
>   language. You are talking about a "decision process", but for the time
> being
>   I see Richard and you trying really hard to make everyone believe there
> is
>   some kind of fair debate.
>
> - The original proposal comes from someone who is not part of the Erlang
> team.
>   You, as part of the Erlang team, immediately sided with him and started
>   engaging with everyone in favor of the proposition. There has been talks
>   about going forward with making the operator mandatory, changing scoping
>   rules, still more changes... So yes, there is an agenda.
>
> - As for "the community not wanting this feature", there are indeed lots of
>   developers here who believe that this kind of change is a mistake (I'm
>   obviously not talking about an optional warning, since it would not
> modify
>   the language), I'm saying it directly because it is true.
>
> At the end of the day, this is about a proposition which, if adopted, could
> change a core aspect of the language in a non-backward compatible way and
> which would force all developers all around the world to eventually change
> all
> their code. And this is being discussed with you as single member of the
> Technical Board.
>
> If you are the only one in charge of taking the final decision, then it is
> clear there is no real debate since you are obviously very much in favour.
> If
> you are not, then there is no real point in arguing for weeks without an
> official answer from the Erlang team.
>
> --
> Nicolas Martyanoff
> http://snowsyn.net
> khaelin@REDACTED
>


-- 
*Karl Nilsson*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210122/200cdd57/attachment.htm>