Re: [Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055
Stanislav Ledenev <[email protected]> Mon, 25 Apr 2022 09:36:32 +0300
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <CAOkK=AKpFWLgXYdh5=it5=ChP78GQ1Bg=iXm-vXVRUDD+iAvSw@mail.gmail.com> |
--00000000000087abf805dd74ccf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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". =D0=BF=D0=BD, 25 =D0=B0=D0=BF=D1=80. 2022 =D0=B3. =D0=B2 08:29, zxq9 <zxq9@= zxq9.com>: > 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 > > <[email protected]> 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/295= 1) > 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=E2=80=99s 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=E2=80=99s not clear to me wh= at > happened after that. > >> > >> Of course, since I=E2=80=99m raising this topic, I=E2=80=99m obviously= in favor of the > operator I=E2=80=99d 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. > >> > >> > --00000000000087abf805dd74ccf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Agree. Unfortunately some of the latest EEPs (IMHO) are a = sign of leaving Erlang's way=C2=A0<div>of doing stuff in the style of &= quot;we have a problem let's find a solution" to a way of modern= =C2=A0</div><div>fancy languages of "let's invent a problem and fi= nd a solution (which becomes another problem to solve)".<br><br>And fu= rthermore in this particular EEP there's this thing I hate more than an= ything else - turning language X to language Y.=C2=A0</div><div>Quote - &qu= ot;This is known as "pinning" in Elixir - see the Elixir document= ation."=C2=A0</div><div>If you like Elixir do your job with Elixir. Wh= y spoil Erlang?=C2=A0</div><div>Especially when, quote - "In current E= rlang, this behaviour is what happens automatically...".<br><br>All th= is nonsense with adding this to the language will "make programs more = readable".=C2=A0</div><div>In all history adding more language constru= ctions never improved</div><div>=C2=A0anything in any language. Look at C++= , C++ 20 and C++ 11 are totally different languages!<br><br>Unfortunately, = the more I code (20+ years), the more I see programming=C2=A0</div><div>lan= guages tombstones with the epitaph "I've been improved and died&qu= ot;.<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class= =3D"gmail_attr">=D0=BF=D0=BD, 25 =D0=B0=D0=BF=D1=80. 2022 =D0=B3. =D0=B2 08= :29, zxq9 <<a href=3D"mailto:[email protected]">[email protected]</a>>:<br></= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0From the EEP, w= hich is about "pinning operators" (will the nonsense<br> cease?):<br> =C2=A0> In Erlang, they would be optional<br> <br> So why would you even want this? The entire idea is stupid, *implies* a<br> break with the basic rules already built into the language, and appears<br> to be nothing more than a way to roadmap the destruction of Erlang over<br> time with gee-whiz glyphy syntax of the sort which Erlang has been thus<br> far generally free.<br> <br> That's a big "NO" from me on this EEP, but I imagine anyone c= ould have<br> already guessed that. Thanks for the heads up. I don't expect sanity to= <br> prevail over time -- it is just the trend of the times -- but it was<br> interesting to at least see this mentioned to those of us still<br> subscribed to the bad dirty old ML.<br> <br> -Craig<br> <br> On 2022/04/21 21:32, Leonard Boyce wrote:<br> > I'm copying the Erlang Questions ML with this post since there was= <br> > significant and heated discussion regarding this EEP and not all ML<br= > > subscribers have joined the forum.<br> > <br> > On Wed, Apr 20, 2022 at 10:20 PM Bryan Paxton via Erlang Forums<br> > <<a href=3D"mailto:[email protected]" target=3D"_blank">nore= [email protected]</a>> wrote:<br> >><br> >> starbelly EEF Board<br> >> April 21<br> >><br> >> EEP-0055 (<a href=3D"https://github.com/erlang/eep/blob/master/eep= s/eep-0055.md" rel=3D"noreferrer" target=3D"_blank">https://github.com/erla= ng/eep/blob/master/eeps/eep-0055.md</a>) was submitted on<br> >> 21-Dec-2020.<br> >><br> >> An accompanying implementation (<a href=3D"https://github.com/erla= ng/otp/pull/2951" rel=3D"noreferrer" target=3D"_blank">https://github.com/e= rlang/otp/pull/2951</a>) was submitted in which a lot of conversation ensue= d.<br> >><br> >> 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 prio= r to OTP-25. OTP-25 is now at a point where this is not possible.<br> >><br> >> That said, I wanted to start a topic here about the EEP and gun fo= r inclusion in OTP-26.<br> >><br> >> I would point to @kennethL=E2=80=99s last comment (<a href=3D"http= s://github.com/erlang/otp/pull/2951#issuecomment-770878570" rel=3D"noreferr= er" target=3D"_blank">https://github.com/erlang/otp/pull/2951#issuecomment-= 770878570</a>) on the PR as a starting point for discussion.<br> >><br> >> I suppose my overarching question here is : Is this still on the t= able? And if so, what are the road blocks? Kenneth pointed out some possibl= e roadblacks that needed investigation, but it=E2=80=99s not clear to me wh= at happened after that.<br> >><br> >> Of course, since I=E2=80=99m raising this topic, I=E2=80=99m obvio= usly in favor of the operator I=E2=80=99d also be happy to work to drive it= forward.<br> >><br> >> ________________________________<br> >><br> >> Visit Topic or reply to this email to respond.<br> >><br> >> You are receiving this because you enabled mailing list mode.<br> >><br> >> To unsubscribe from these emails, click here.<br> >><br> >><br> </blockquote></div> --00000000000087abf805dd74ccf4--