New EEP draft: Pinning operator ^ in patterns

[Nicolas Martyanoff]

On 2021-01-28 23:21, Austin Ziegler wrote:
> I’ve seen straw-men raised that functions should be small. As a rule,
> that’s too strict. Functions should be as small as it makes sense to
> express their concept. In most of the ~30 languages I’ve written
> software in over my career, I usually start with larger functions and
> then refactor them out as it makes sense to do so and the
> expressiveness of the containing function is improved by the
> refactoring. 
Keeping functions small is an important rule in every language I ever wrote
code with. Without any exception. It has nothing to do with the language, but
the fact that the longer the function is, the harder it is to build a complete
mental model of the way it works. Small functions are easier to read and
understand; and they compose better.

> So, if one had no interest in the implementation of maps, one can
> simply ignore the fact that the syntax and feature exist in modern
> Erlang…and any libraries that one might use? All syntax changes have a
> negative impact on someone’s view of readability.
Maps were not introduced because some developers had trouble understanding
code without them; they were introduced because not having an efficient
associative container is a deal breaker for tons of use cases. For example,
before the introduction of maps in OTP 17, I could never do anything serious
with Erlang because records were (and still are) a huge PITA. Maps are one of
the features that made me start using Erlang for real world use cases (rebar3
is another one).

But the important thing here is that maps are just an additional feature;
a pinning operator made mandatory would change the way pattern matching is
used. And of course, everytime this is said, we are being told it would not be
mandatory. At first. So it will be at some point, same result.

> Richard has worked with a large Erlang codebase with a large
> team, and that team noticed something that cost real developer time
> and velocity. Thus, this suggestion that could make adoption of Erlang
> at team scales an easier sale to management.
What does it have to do with selling to management ? This is insane, you do
not design a programming language to please management. Unless of course you
hope Erlang becomes the new Java or Go.

Beyond the fact that various companies already use Erlang, no one is going to
start using Erlang because there is a pinning operator, this just does not
make any kind of sense.

> Aside from the fact that I don’t agree with you about this being
> useful only if mandatory, what exactly is wrong with a likely ~4–5
> year schedule for this sort of change? I’ve seen _plenty_ of breaking
> changes listed in the last 5 years of release notes on the Erlang
> website (at least one syntax / warning change, and many more changes
> to things like erlang_interface and parts of the stdlib which have had
> functions dropped after 1–2 versions).
As you will easily understand, if someone believe that this kind of
modification to a core concept of the language is a bad thing, arguing it will
only happen in a couple years is not going to change their mind.

> > It changes the way pattern matching works, so when it is made mandatory it is breaking by definition.
> Not initially. And it may never be made mandatory if it turns out that
> there’s no adoption of the feature (frankly, I think that people will
> adopt the feature because it will likely make onboarding new
> developers who may also be new to Erlang faster).
I saw a couple people onboarded on Erlang, one very recently. Names used in
bindings and pattern matches have *never* be an issue. Problems always came
from the tooling (more precisely the lack thereof), the
string/binary/unicode:chardata insanity, having to deal with records,
an extremely limited standard library (I'm looking at you calendar), etc.

Arguing that it "may" never be made mandatory if it is not being used is
not even funny: it has been made clear in previous messages that this is part
of a plan which originated at WhatsApp to change various aspects of the
language. This clearly means that there is going to be more of this kind of
proposition. And do not even get me started on the hints that some people want
to change scoping rules, this is beyond insane. 

This discussion has become pointless. I asked who was actually in a position
to accept or reject this kind of proposal, so that we can get an authoritative
response, but I still have not seen anyone. I believe a lot of confusion here
comes from the fact that no one has any idea where this is going: what is the
vision of the OTP team regarding the language itself ? Do they intend to
integrate this kind of change ? Would they agree to a change in a scoping
rules ? Do they have a vision, or will they let anyone add their pet feature
to the language, transforming it into the same big ball of mud so many other
languages have become ?

If there was an official move to transform Erlang at a level that fundamental,
it would be nice to know in advance. On the other hand, if the OTP team was
committed to keep the core language stable, it would be reassuring to be told
so.

-- 
Nicolas Martyanoff
http://snowsyn.net
khaelin@REDACTED