New EEP draft: Pinning operator ^ in patterns
Fri Jan 15 18:32:21 CET 2021
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 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
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.
More information about the erlang-questions