Re: [Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055
Karl Velicka <[email protected]> Mon, 25 Apr 2022 10:16:06 +0100
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <CANxL2L7hu3PLs57BcrxYQwcbVwDk+X8sDirF4jxq928u4QV_CA@mail.gmail.com> |
--0000000000005a281d05dd7707a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Isn't that being at least a bit exaggerated/hyperbolic? Erlang has fairly glyphy <<"binaries">>, $c $h $a $r $s are also not entirely glyph-free, and neither are ?MACROS. Or the "send" operator (!), though it's not often used in production code in my experience. While I'm not massively for this particular EEP (I'd describe my position as ambivalent - I'd use it if it made it in, but I'll lose zero sleep if it doesn't), it feels like some people in this list (and this is most definitely not aimed at Craig in particular!) are laying the hyperbole on thick. A few key points appear to be "new =3D=3D bad", "comes from elixir = =3D=3D bad", "look at C++ and how terrible that is going". So, I'd like to raise some questions in response: * Do people here genuinely feel that Erlang is in its global optimum state right now and there are no positive improvements that can be made? * Do people here genuinely believe that Elixir is strictly a bad thing, no positive things can come of it, and any ideas that in some way originate from Elixir is some kind of plague? * Lastly, there's a theme of taking potshots at C++. While it is true that its evolution brought some bad things along with the good, I've not heard a single C++ developer wishing that they could move their codebase(s) back to an older C++ standard, which actually happens to be entirely feasible in C++ ecosystem (some people/orgs run some _very_ old codebases, and as a result ancient codebases are supported by newest versions of compilers). So, how bad is the situation in "modern" C++ land really..? (this last question is more rhetoric - I do not with to start a lengthy discussion about merits of C++'s new additions in an Erlang mailing list) There's also some suggestions of how Erlang _should_ evolve. Those include things that I also consider good ideas, but in some cases making them a reality can be tricky because one has to work out a backwards compatibility strategy, provide some reference implementation etc. Criticising such work produced by others is on the other hand relatively easy. So I ask the proposers - how are _you_ contributing to a more "Erlang-y" future of the language? where are your EEPs? It's clear that some people in the community use Erlang extensively enough to face some issues with the language, and they're trying to make suggestions on how these might be improved. What we get from the mailing list community is a bunch of claims about how the proposers' problems are not real problems and/or their solutions are literally killing the language. So, my last question is - doesn't this kind of attitude have some elements of cutting the branch we (as the Erlang community) are sitting on..? I hope my questions didn't offend anyone (and particularly people whose points I referenced in my mail) - I've been a reader of the mailing list for many years and learned a lot from the regular posters here. However, there's been a few "incidents" over the years where some seemingly small things got blown completely out of proportion, and I think the community would be better off if its members firstly assumed overall positive intent (even though it might have downsides for some individual users), and took a few deep breaths before hitting "send", particularly in cases where typing up your response was a blood-pressure-raising activity. I wish everyone all the best, and I hope that this (and future) discussions could get a tiny bit less emotionally charged. Karl On Mon, 25 Apr 2022 at 06:29, zxq9 <[email protected]> wrote: > 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. > >> > >> > --0000000000005a281d05dd7707a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Isn't that being at least a bit exaggerated/hyper= bolic? Erlang has=20 fairly glyphy <<"binaries">>, $c $h $a $r $s are also= not=20 entirely glyph-free, and neither are ?MACROS. Or the "send" opera= tor=20 (!), though it's not often used in production code in my experience.</d= iv><div><br></div><div>While I'm not massively for this particular EEP (I'd describe my positio= n as=20 ambivalent - I'd use it if it made it in, but I'll lose zero sleep = if it doesn't), it feels like some people in this list (and this is most=20 definitely not aimed at Craig in particular!) are laying the hyperbole=20 on thick. A few key points appear to be "new =3D=3D bad", "c= omes from elixir =3D=3D bad", "look at C++ and how terrible that is going". = So, I'd like to=20 raise some questions in response: <br></div><div><br></div><div>* Do=20 people here genuinely feel that Erlang is in its global optimum state=20 right now and there are no positive improvements that can be made?<br></div= ><div>* Do people here genuinely believe that Elixir is strictly a bad thing,=20 no positive things can come of it, and any ideas that in some way=20 originate from Elixir is some kind of plague?</div><div>* Lastly,=20 there's a theme of taking potshots at C++. While it is true that its=20 evolution brought some bad things along with the good, I've not heard a= =20 single C++ developer wishing that they could move their codebase(s) back to an older C++ standard, which actually happens to be entirely=20 feasible in C++ ecosystem (some people/orgs run some _very_ old=20 codebases, and as a result ancient codebases are supported by newest=20 versions of compilers). So, how bad is the situation in "modern" = C++=20 land really..? (this last question is more rhetoric - I do not with to=20 start a lengthy discussion about merits of C++'s new additions in an=20 Erlang mailing list)</div><div><br></div><div>There's also some=20 suggestions of how Erlang _should_ evolve. Those include things that I=20 also consider good ideas, but in some cases making them a reality can be tricky because one has to work out a=C2=A0 backwards compatibility strateg= y, provide some reference implementation etc. Criticising such work=20 produced by others is on the other hand relatively easy. So I ask the=20 proposers -=C2=A0 how are _you_ contributing to a more "Erlang-y"= =C2=A0 future of=20 the language? where are your EEPs? It's clear that some people in the= =20 community use Erlang extensively enough to face some issues with the=20 language, and they're trying to make suggestions on how these might be= =20 improved. What we get from the mailing list community is a bunch of=20 claims about how the proposers' problems are not real problems and/or= =20 their solutions are literally killing the language. So, my last question is - doesn't this kind of attitude have some elements of cutting the= =20 branch we (as the Erlang community) are sitting on..?</div><div><br></div><= div>I hope my questions didn't offend anyone (and particularly people whose= =20 points I referenced in my mail) - I've been a reader of the mailing lis= t for many years and learned a lot from the regular posters here.=20 However, there's been a few "incidents" over the years where = some=20 seemingly small things got blown completely out of proportion, and I=20 think the community would be better off if its members firstly assumed=20 overall positive intent (even though it might have downsides for some=20 individual users), and took a few deep breaths before hitting "send&qu= ot;,=20 particularly in cases where typing up your response was a=20 blood-pressure-raising activity.</div><div><br></div><div>I wish everyone a= ll the best, and I hope=C2=A0 that this (and future) discussions could get = a tiny bit less emotionally charged.</div><div><br></div><div>Karl</div></d= iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On = Mon, 25 Apr 2022 at 06:29, zxq9 <<a href=3D"mailto:[email protected]">zxq9@z= xq9.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex">=C2=A0From the EEP, which is about "pinning operators" (wi= ll 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> --0000000000005a281d05dd7707a8--