[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

[Stanislav Ledenev]

Agree. Unfortunately some of the latest EEPs (IMHO) are a sign of leaving
Erlang's way
of doing stuff in the style of "we have a problem let's find a solution" to
a way of modern
fancy languages of "let's invent a problem and find a solution (which
becomes another problem to solve)".

And furthermore in this particular EEP there's this thing I hate more than
anything else - turning language X to language Y.
Quote - "This is known as "pinning" in Elixir - see the Elixir
documentation."
If you like Elixir do your job with Elixir. Why spoil Erlang?
Especially when, quote - "In current Erlang, this behaviour is what happens
automatically...".

All this nonsense with adding this to the language will "make programs more
readable".
In all history adding more language constructions never improved
 anything in any language. Look at C++, C++ 20 and C++ 11 are totally
different languages!

Unfortunately, the more I code (20+ years), the more I see programming
languages tombstones with the epitaph "I've been improved and died".

пн, 25 апр. 2022 г. в 08:29, zxq9 <zxq9@REDACTED>:

>  From the EEP, which is about "pinning operators" (will the nonsense
> cease?):
>  > In Erlang, they would be optional
>
> So why would you even want this? The entire idea is stupid, *implies* a
> break with the basic rules already built into the language, and appears
> to be nothing more than a way to roadmap the destruction of Erlang over
> time with gee-whiz glyphy syntax of the sort which Erlang has been thus
> far generally free.
>
> That's a big "NO" from me on this EEP, but I imagine anyone could have
> already guessed that. Thanks for the heads up. I don't expect sanity to
> prevail over time -- it is just the trend of the times -- but it was
> interesting to at least see this mentioned to those of us still
> subscribed to the bad dirty old ML.
>
> -Craig
>
> On 2022/04/21 21:32, Leonard Boyce wrote:
> > I'm copying the Erlang Questions ML with this post since there was
> > significant and heated discussion regarding this EEP and not all ML
> > subscribers have joined the forum.
> >
> > On Wed, Apr 20, 2022 at 10:20 PM Bryan Paxton via Erlang Forums
> > <noreply@REDACTED> wrote:
> >>
> >> starbelly EEF Board
> >> April 21
> >>
> >> EEP-0055 (https://github.com/erlang/eep/blob/master/eeps/eep-0055.md)
> was submitted on
> >> 21-Dec-2020.
> >>
> >> An accompanying implementation (https://github.com/erlang/otp/pull/2951)
> was submitted in which a lot of conversation ensued.
> >>
> >> It was decided that the EEP would not be set for inclusion in OTP-24,
> per the time table at that juncture and that it would be revisited prior to
> OTP-25. OTP-25 is now at a point where this is not possible.
> >>
> >> That said, I wanted to start a topic here about the EEP and gun for
> inclusion in OTP-26.
> >>
> >> I would point to @kennethL’s last comment (
> https://github.com/erlang/otp/pull/2951#issuecomment-770878570) on the PR
> as a starting point for discussion.
> >>
> >> I suppose my overarching question here is : Is this still on the table?
> And if so, what are the road blocks? Kenneth pointed out some possible
> roadblacks that needed investigation, but it’s not clear to me what
> happened after that.
> >>
> >> Of course, since I’m raising this topic, I’m obviously in favor of the
> operator I’d also be happy to work to drive it forward.
> >>
> >> ________________________________
> >>
> >> Visit Topic or reply to this email to respond.
> >>
> >> You are receiving this because you enabled mailing list mode.
> >>
> >> To unsubscribe from these emails, click here.
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220425/c102f3cc/attachment.htm>