<div dir="ltr">I'll speak for myself.<br><br>>> * Do people here genuinely feel that Erlang is in its global optimum <br>>> state right now and there are no positive improvements that can be<br>>> made?<br><br>I think that Erlang as a language is quite close to its optimal <br>state: quite strict and simple (though powerful) syntax, <br>convenient modules concept, powerful OTP e.t.c.<br>Anything that I'll ever need can be implemented through libraries. <br>And the only language change which I'll be glad for is a native utf-8 string support.<br>Of course there are few libraries but it brings unneeded variations of implementations.<br><br>>> * Do people here genuinely believe that Elixir is strictly a bad thing, <br>>> no positive things can come of it, and any ideas that in some way <div>>> originate from Elixir is some kind of plague?<br><br>I don't like Elixir because it is a category of syntactic sugar language which I <br>don't think is any good. But it is as it is and let it be. <br>What I hate most and this is very important is those changes to Erlang <br>rationalized by examples of the other language. <br>It is a road to hell. <br>For example, imagine what would happen if some ideas were brought to the Erlang <br>if we took some stuff from LFE(Lisp flavoured Erlang) to the core?<br><br>>> * Lastly, there's a theme of taking potshots at C++. While it is true <br>>> that its evolution brought some bad things along with the good, I've <br>>> not heard a single C++ developer wishing that they could move <br>>> their codebase(s) back to an older C++ standard, which actually <br>>> happens to be entirely feasible in C++ ecosystem (some people/orgs run some _very_ old codebases, and as a result <br>>> ancient codebases are supported by newest versions of compilers). <br>>> So, how bad is the situation in "modern" C++ land really..? <br>>> (this last question is more rhetoric - I do not with to start a lengthy <br>>> discussion about merits of C++'s new additions in an Erlang mailing list)<br><br>I strongly recommend to read this little paper of Bjarne Stroustrup<br><a href="https://www.stroustrup.com/P0977-remember-the-vasa.pdf">https://www.stroustrup.com/P0977-remember-the-vasa.pdf</a><br><br>excerpt: "...so my reading of the Vasa story is: Work hard on a solid foundation, learn from<br>experience, and don’t scrimp on the testing.<br><br>The foundation begun in C++11 is not yet complete, and C++17 did little to make our<br>foundation more solid, regular, and complete. Instead, it added significant surface complexity<br>and increased the number of features people need to learn. C++ could crumble under the<br>weight of these – mostly not quite fully-baked – proposals. We should not spend most of our time<br>creating increasingly complicated facilities for experts, such as ourselves."<br><br>I mention C++ as an example of weird language evolution (?). C++ is evolving but<br>in a strange way. It's always becoming more and more complex, not the opposite.<br>If anyone writes C++ as it is he/she must write more and more code to solve<br>same old problems. As one of the examples - "Rule of three" became "Rule of five".<br><br>At the same time there were so many languages which promoted themself as a "C++ killer" but C++ is still alive.<br>The problem with C++ - it kills itself. C++ is slowly dying. I can hardly<br>see any young software developers who wish to learn C++. They must learn so many<br>weird concepts to get so little. Even memory management with C is much easier<br>they can understand than this crap "rvalue"/"lvalue" stuff with copy, copy-assign, move etc.<br><br>I'd be more sad if this happens with Erlang.<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 25 апр. 2022 г. в 12:16, Karl Velicka <<a href="mailto:karolis.velicka@gmail.com">karolis.velicka@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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 == bad", "comes from elixir
 == bad", "look at C++ and how terrible that is going". So, I'd like to 
raise some questions in response: <br></div><div><br></div><div>* 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?<br></div><div>*
 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?</div><div>* 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)</div><div><br></div><div>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..?</div><div><br></div><div>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.</div><div><br></div><div>I wish everyone all the best, and I hope  that this (and future) discussions could get a tiny bit less emotionally charged.</div><div><br></div><div>Karl</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 25 Apr 2022 at 06:29, zxq9 <<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> From the EEP, which is about "pinning operators" (will the nonsense<br>
cease?):<br>
 > 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 could 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="mailto:noreply@erlangforums.com" target="_blank">noreply@erlangforums.com</a>> wrote:<br>
>><br>
>> starbelly EEF Board<br>
>> April 21<br>
>><br>
>> EEP-0055 (<a href="https://github.com/erlang/eep/blob/master/eeps/eep-0055.md" rel="noreferrer" target="_blank">https://github.com/erlang/eep/blob/master/eeps/eep-0055.md</a>) was submitted on<br>
>> 21-Dec-2020.<br>
>><br>
>> An accompanying implementation (<a href="https://github.com/erlang/otp/pull/2951" rel="noreferrer" target="_blank">https://github.com/erlang/otp/pull/2951</a>) was submitted in which a lot of conversation ensued.<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 prior 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 for inclusion in OTP-26.<br>
>><br>
>> I would point to @kennethL’s last comment (<a href="https://github.com/erlang/otp/pull/2951#issuecomment-770878570" rel="noreferrer" target="_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 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.<br>
>><br>
>> 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.<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>
</blockquote></div>