New EEP draft: Pinning operator ^ in patterns

zxq9 zxq9@REDACTED
Thu Jan 28 10:57:04 CET 2021

On 2021/01/28 18:25, Richard Carlsson wrote:
> Den tors 28 jan. 2021 kl 07:19 skrev Nicolas Martyanoff 
> <khaelin@REDACTED <mailto:khaelin@REDACTED>>:
>     I really wish people who want to see a language go a different way
>     just create
>     a new language of their own instead of messing with what exists and
>     is liked
>     as it is. José Valim did it successfully with Elixir, so yes it is
>     possible.
> If the people who rely on Erlang for their businesses and their jobs 
> have needs that are not fulfilled by the language as it is, then either 
> the language can evolve or those users will eventually move to another 
> language, either on Beam or on some other platform, leaving Erlang in 
> the eternal maintenance realm of Cobol, with no new systems being 
> written in it, and no new users apart from those dragged in to keep some 
> old system running. Would you prefer that? If Ericsson and others found 
> a way to transition to Elixir, for example, would anyone keep paying for 
> maintenance of Erlang? At least Cobol has a lot of money behind it 
> still. If evolution is possible, then it is always preferable to 
> creating a competing dialect.

Changes that move directly against one of the most basic core concepts 
of the language are not only a disservice to existing codebases written 
with those core concepts in mind, but also leaves homeless users who are 
attracted to Erlang specifically because of those core concepts.

This amounts to a "well, if you don't like it YOU should be the one to 
go make a new language that is like current Erlang, but maybe without 
shadowing since it is such a horrible, terrible thing that is ruining so 
many codebases" position.

To that I say "NO U!"
[Insert Spiderman pointing at Spiderman meme] (^.^)

Doubleplus ungood.

Using COBOL as an example is a bit hilarious. Have you actually written 
a project in it? Have you seen the "evolution" of this language? It is 
patently ridiculous, to the point that the only two projects I've ever 
done paid work in using it explicitly forbade use of "modern" constructs 
because they were confusingly implemented and a total mess. C++ comes to 
mind as well. These languages are suffering from wetware 
incompatibility: they are so convoluted and overloaded with garbage 
unfeatures that the first thing any project manage must determine is 
what subset of the stupid language is the "safe" subset. This isn't the 
exception, this is the rule with any language that undergoes "evolution" 
and is not at all what determines whether a language gains or loses users.

Python retained its crown for so long by *refusing* feature additions, 
and is now likely doomed to a Java/C++-esque future now that Guido quit 
over the ridiculous "walrus operator" (yet another glyphy bit of 
uselessness that has an utterly non-obvious name that confounds newcomers).

I'd rather the ecosystem *around* Erlang evolve in directions more 
interesting than "releases everywhere" and other things that confuse 
newcomers rather than messing the core language up. Erlang is already 
fully buzzword compliant, as a matter of fact, and its features predate 
the buzzwords themselves! That's remarkable. Ignoring tooling while 
cobbling more junk into the *language* is the opposite of progress.


More information about the erlang-questions mailing list