<div dir="ltr">So I took the pinning branch for a spin and ran it against the Ra library (<a href="https://github.com/rabbitmq/ra/pull/209">https://github.com/rabbitmq/ra/pull/209</a>) 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! <div>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.</div><div><br></div><div>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.</div><div><br></div><div>Just my 2 öre though...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Jan 2021 at 10:32, Nicolas Martyanoff <<a href="mailto:khaelin@gmail.com">khaelin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2021-01-22 11:02, Raimo Niskanen wrote:<br>
> I am trying again, in hopefully a more civilized manner...<br>
> <br>
> By constantly repeating that your opinion would not matter and that someone<br>
> has a plan to force this feature through you indirectly say:<br>
> *) That the decision process for an EEP and the Technical Board at Erlang/OTP<br>
> at Ericsson can not be trusted to make a good decision for the Erlang<br>
> language and the community.<br>
> *) That the community does not want this feature.<br>
> <br>
> This is attacking the decision process itself instead of contributing to<br>
> the decision. To me this feels like a way to force your point of view<br>
> through in this decision.<br>
<br>
Try to put yourself in the shoes of those who reject the proposal:<br>
<br>
- From the beginning, we are being told repeatedly that our answers do not<br>
address the right part of the proposal, or are not valid arguments, or are<br>
not the right way to argue. The last evolution of the debate is a comparison<br>
to Trump...<br>
<br>
- As I already asked, for all these messages we still have not received any<br>
information about who has real authority on this type of change to the<br>
language. You are talking about a "decision process", but for the time being<br>
I see Richard and you trying really hard to make everyone believe there is<br>
some kind of fair debate.<br>
<br>
- The original proposal comes from someone who is not part of the Erlang team.<br>
You, as part of the Erlang team, immediately sided with him and started<br>
engaging with everyone in favor of the proposition. There has been talks<br>
about going forward with making the operator mandatory, changing scoping<br>
rules, still more changes... So yes, there is an agenda.<br>
<br>
- As for "the community not wanting this feature", there are indeed lots of<br>
developers here who believe that this kind of change is a mistake (I'm<br>
obviously not talking about an optional warning, since it would not modify<br>
the language), I'm saying it directly because it is true.<br>
<br>
At the end of the day, this is about a proposition which, if adopted, could<br>
change a core aspect of the language in a non-backward compatible way and<br>
which would force all developers all around the world to eventually change all<br>
their code. And this is being discussed with you as single member of the<br>
Technical Board.<br>
<br>
If you are the only one in charge of taking the final decision, then it is<br>
clear there is no real debate since you are obviously very much in favour. If<br>
you are not, then there is no real point in arguing for weeks without an<br>
official answer from the Erlang team.<br>
<br>
-- <br>
Nicolas Martyanoff<br>
<a href="http://snowsyn.net" rel="noreferrer" target="_blank">http://snowsyn.net</a><br>
<a href="mailto:khaelin@gmail.com" target="_blank">khaelin@gmail.com</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><b>Karl Nilsson</b></div></div></div>