<div dir="ltr"><div dir="ltr">On Mon, Apr 25, 2022 at 11:27 AM Michael Malter <<a href="mailto:airlangue@gmail.com">airlangue@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">Well I would rather let Joe rest in peace but the reference is probably helpful there.<div dir="auto"><br></div><div dir="auto">Erlang is simple. I mean, that's how Joe saw it. He expressed it multiple times.</div></div></blockquote><div><br></div><div>Simple is in the eye of the beholder. I would disagree with the assessment that Erlang is simple, but From a Certain Point of View, it is, sure. Is it simpler than Elixir? In some ways, yes. In other ways, no. If you’re trying to say that Erlang is a <b>small</b> language, then I’d mostly agree. So is Elixir, though. From certain points of view, Elixir is much easier to apprehend than Erlang, because Erlang is more sparse than Elixir. As a language.</div><div><br></div><div>That said, it took me a <b>long</b> time to understand `=:=` because it’s a complex, compound sigil (not used _that_ frequently) that I’ve never seen in any other language (and I know quite a few). To _me_, `^Value -> …` is clearer than `NewValue when Value =:= NewValue`. But that’s me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">Do you remember the time when that was the Java motto ? Look at Java now.</div></div></blockquote><div><br></div><div>I never remember such a day. Granted, it got much worse after the introduction of J2EE and all that crap, but I never remember Java being "simple".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Is it so hard to understand what we are saying ? For once it's pretty clear and without many diverging opinions.</div></div></blockquote><div> </div><div>Except that there <b>are</b> numerous diverging opinions. They just tend to be drowned out by louder people who can’t seem to express their opposition in the simple, clear terms that you and Loïc have, and instead are making purely emotional expressions.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">- it's not sufficiently useful to warrant another language features (you know, less is more)</div><div dir="auto">- it's yet another sigil and we hate them. </div></div></blockquote><div><br></div><div>The former is arguable, and I’ve seen little in any of the threads about this EEP to suggest that this is the case. The latter is a matter of taste, but it’s also a legitimate concern. New sigils shouldn’t be added without good reason. I’ve seen such discussions in Elixir and Ruby language discussions, and sometimes a new sigil gets added (`&.` and `->()` in Ruby; I like the former, hate the latter, although I use it).</div><div><br></div><div>Not addressed in the original EEP (probably because it wasn’t originally considered) is whether expressing pinning might improve the compiler’s ability to generate better code. It’s been raised on the forum though, and it should be considered. If nothing else, it starts to indicate that there may be more use than simply avoiding guard clauses (which IMO is worthy in and of itself).</div><div><br></div><div>-a</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 25 avr. 2022 à 17:14, Austin Ziegler <<a href="mailto:halostatue@gmail.com" target="_blank">halostatue@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Apr 25, 2022 at 10:58 AM Stanislav Ledenev <<a href="mailto:s.ledenev@gmail.com" rel="noreferrer" target="_blank">s.ledenev@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>One question - why? Just because we can?</div><div>Erlang is doomed, Sorry Joe, we f**d things up.</div></div></blockquote><div> </div></div>I really can’t help but laugh at over the top reactions like this and those who can’t help but bash Elixir because they don’t like the syntax.<div><br></div><div>What if this syntax (or some other syntax) helps the compiler generate better (safer, faster, <i>whatever</i>) code? How would anyone know unless it gets tried? Why would anyone want to try it when they know that a certain vocal subset of the community are going to be pitching embarrassing fits over it?</div><div><br></div><div>If this is introduced in OTP 26, then stop upgrading. Seriously. Stay on OTP 25 or before. But seriously, stop acting like children about this and saying that things are fucked up (because they’re not; you just don’t like this because you don’t like it). The only <i>real</i> objection that I’ve seen that makes sense to me is from Loïc, which is that it might be better to enable <i>annotations</i>, even if the only annotation initially available is for pinning. (My personal feeling on the annotation concept is that `^pin Variable` doesn’t feel right to me, but maybe `^pin:Variable` or `^pin{Variable}` or `^{pin}Variable` or something else, although more sigil-y, would be clearer.</div><div><br></div><div>I mostly use Elixir, but often read Erlang codebases. On the Elixir core mailing list, there are frequent redirects to approach something as a possible PR to Erlang/OTP because it’s something that should benefit all BEAM languages.</div><div><br></div><div>Telemetry started as an Elixir library, but was quickly changed to a pure Erlang approach because it makes more sense to be something that all BEAM languages can use.</div><div><br></div><div>Elixir has — and I suspect both LFE and Gleam both have — <i>enhanced </i>the BEAM through wider exposure, code contributions, and other contributions. If you can’t argue a feature request like in this EEP on its merits (or lack thereof) without trying to bash Elixir, then maybe you don’t actually have an argument, but an emotional outburst, and should just <i>discard</i> your rant after writing it.<br><div><div><div><br></div><div>-a<br>-- <br><div dir="ltr">Austin Ziegler • <a href="mailto:halostatue@gmail.com" rel="noreferrer" target="_blank">halostatue@gmail.com</a> • <a href="mailto:austin@halostatue.ca" rel="noreferrer" target="_blank">austin@halostatue.ca</a><br><a href="http://www.halostatue.ca/" rel="noreferrer" target="_blank">http://www.halostatue.ca/</a> • <a href="http://twitter.com/halostatue" rel="noreferrer" target="_blank">http://twitter.com/halostatue</a></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Austin Ziegler • <a href="mailto:halostatue@gmail.com" target="_blank">halostatue@gmail.com</a> • <a href="mailto:austin@halostatue.ca" target="_blank">austin@halostatue.ca</a><br><a href="http://www.halostatue.ca/" target="_blank">http://www.halostatue.ca/</a> • <a href="http://twitter.com/halostatue" target="_blank">http://twitter.com/halostatue</a></div></div>