Re: New EEP draft: Pinning operator ^ in patterns

On 2021/01/16 0:35, Raimo Niskanen wrote:
> And I want to get clarity about exactly why so many developers are worried
> about this particular proposed change, and therefore try to look thoroughly
> at the arguments.
> 
> It is as you say a fundamental detail in the language.
> 
> 1) Would the language be a better language with a mandatory pinning operator?

At the cost of *adding* something arbitrarily hard to research[1] syntax 
to "solve" a problem that is demonstrated to not be at all a problem in 
the testimony of every voice on list? The real problem, as has been 
highlighted repeatedly, is naive programmers writing too-large 
convoluted functions. If you can't tell where a variable was assigned in 
a single-assignment you need better glasses or shorter functions.

The answer is "no".

1. How would someone on encountering this syntax the first time propose 
to search for whatever it is called to find it in the docs? The names of 
syntaxy things are NOT obvious. It took me quite a while to discover 
there is this new stupid thing in Python called the "walrus operator" 
that eliminates the need for one line of code in a rather arbitrary and 
unusual case. I found out about it only by asking in IRC -- there was no 
possible way for me to discover it in offline documentation alone (which 
itself is dangerous "But *I've* always got an internet connection when 
working, why don't *YOU*?!?" herp derp). Why did I need to find out 
about it? Because I saw some code where someone had used it *once* and 
needed to understand what was going on. That's a pretty stupid thing to 
do to a language with users with decades of experience who have fully 
embraced a core mantra of the language: "there should be one, and 
preferably only one, right way to do it".

Adding syntax should never be done flippantly. The old saw about the 
"cancer of the semicolons" should be respected for what it is: hard-won 
wisdom.

For the record:
   Functions > Operators
   Functions > Syntax

There are limits to the above, but once a language is actually usable 
additions tend to work better through functions than syntax cobble.

This is true to such a fundamental degree that I am somewhat annoyed 
that we don't have BIFs for the arithmetic operators to which infix 
operators transform. Write some mathish code a bit and you'll 
immediately see why. Adding syntax is fully in the infix operator realm 
of dysfunction as regards language design. Almost comical this 
discussions is occurring in a community commonly thought of as a 
stronghold of FP principles.

We have a single reasonable coding practice right now: don't mask 
variables in funs. We have a warning about it. Best practice leans a 
single direction. Do you want to *divide* best practice? That's a silly 
thing to do, but when you're in the language designer's seat with all 
these genius ideas that the Good Idea Fairy craped out on your shoulder 
about how to implement it and how great everything will be for *you* 
once implemented and how much praise you can get for implementing it you 
don't see things that way.

Do we believe the original designers introduced a *flaw* by not 
including such a thing?

How much support have we seen by actual coders here for it? Reactions 
seem to range from sitting on the fence to "oh please wtf no!" But being 
stunning and brave in the face of adversity is what 2020 was all about, 
so why not 2021?

Elixir is ready and waiting. Perhaps use that instead if you want to 
completely max out the ASCII chart in your source files?

This is a strongly worded response. I don't like just being negative, so 
to end on a higher note let me express the OVERWHELMINGLY POSITIVE thing 
about Erlang that is just so so good that I am compelled to defend the 
language as it exists against arbitrary syntax additions...

Erlang is amazing as a productivity tool. It's amazing. Part of why it 
is amazing is because it has managed the waterbed problem *very* well by 
having a minimalistic language that drives a hugely complex and 
remarkably capable runtime. I'd much rather effort be put into the 
runtime than the language we use to speak to each other and the runtime. 
Efforts in the runtime have won us ENORMOUS advantages over the years to 
the point that I have some old code that runs fantastically faster today 
wither zero to trivial changes. Wow! Let's keep doing more of that!

We have the JIT coming out. The potential is so huge there that I am 
inspired to agitate for, or maybe implement myself, bindings to cross 
platform audio/video libs because there really isn't anything to prevent 
us from pushing Erlang into a more visible role on the client side 
(hence all that tooling I've written to make client side GUI coding easy 
and make writing Erlang feel like writing other dynamic languages with 
virtenv and so on instead of "releases" for everything).

Don't succumb to the temptation of syntax additions now. It looks like 
it would be a good thing, but for most working coders it will just be a 
weird point of "Oh? Wait... what? What's that thing?" and be awkward to 
remember (and arbitrary to choose to use or disregard) for anyone who 
doesn't work fully in Erlang all the time and be totally unnecessary 
even if they do.

-Craig