<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px"><div id="yui_3_16_0_ym19_1_1505517459498_1645704" dir="ltr"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1505517459498_1645720">> If anything, a "let's put it in Erlang2" approach, based on current </span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1505517459498_1645721"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1505517459498_1645722">> evidence, is much more likely to be horrible and difficult (modula-3, </span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1505517459498_1645723"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1505517459498_1645724">> python3 or perl6 style) than progressive changes being incorporated into </span><br clear="none" style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1505517459498_1645725"><span style="font-family: "Helvetica Neue", "Segoe UI", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1505517459498_1645726">> the language on an ongoing basis.<br></span><span id="yui_3_16_0_ym19_1_1505517459498_1645760"><br>The problem with python 3 is code cannot be run on a python 2 interpreter.<br><br>They royally messed this up by not having backwards compatibility and hence why the transition is <br>so long. OTP seems very good with depreciation and ensuring backwards compatibility.<br><br>I welcome a fully backwards compatible Erlang2, and Erlang3/4/5, as long as we don't have<br>another running Erlang2 from Erlang1 crisis (*cough* elixir).<br><br>If at the end of the day Erlang2 will generate erlang1 compatible beam files everything should be well,<br>then just pick a syntax/language you like (erlang2/3/4/5/9000), compile the beams, run them on BEAM.<br><br>The big problem with why elixir kind of "poisoned" the community in regards to having spinoff languages <br>using beam is because they messed up the elixir compiler. 1-2 features ruined the whole thing and<br>made it a royal mess. Those 2 features are multiple modules per file, and macros. The cost of<br>having these 2 features which are rarely used is very high, to the point elixir cant even hotload properly <br>without fully purging modules (crashes during hotload if you call into a purged module at exact time elixir is<br>hotloading).<br id="yui_3_16_0_ym19_1_1505517459498_1646015"><br id="yui_3_16_0_ym19_1_1505517459498_1646155"><br></span></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Thursday, September 28, 2017 12:33 PM, Fred Hebert <mononcqc@ferd.ca> wrote:<br></font></div> <br><br> <div class="y_msg_container">On 09/29, zxq9 wrote:<br clear="none">>On 2017年09月28日 木曜日 11:33:29 Fred Hebert wrote:<br clear="none">>> I am able to get along fine without it, but if working without a similar<br clear="none">>> construct requires 40 posts in a mailing list to make sure other people<br clear="none">>> get a solution or pattern they are comfortable with when the operator is<br clear="none">>> *not* available, then maybe there's a need to look at ways to improve<br clear="none">>> the current state of things.<br clear="none">><br clear="none">>I get your point, but this is a fantastic mischaracterization of what is<br clear="none">>happening.<br clear="none">><br clear="none"><br clear="none">I'm not necessarily speaking of this specific thread. This conversation <br clear="none">is neither the first nor the last one about this. At work I've recetly <br clear="none">trained a team of 12 people into using Erlang and the questions about <br clear="none">the patterns in this thread have been had there as well. And similarly <br clear="none">for questions from the previous threads -- whether exceptions are the <br clear="none">right tool when it comes to validation.<br clear="none"><br clear="none">>So what IS actually happening?<br clear="none">><br clear="none">>We have an explosion of fad languages that keep adding sexy syntax all<br clear="none">>over the place. People get sort of used to a few of them and then get<br clear="none">>surprised when something new (like matching) is central to this new one<br clear="none">>they're not used to, but feel like things are somehow wrong if one they<br clear="none">>were expecting (like a composition operator, or objects, or whatever) is<br clear="none">>missing.<br clear="none">><br clear="none">>What is happening in that fantabulous language space?<br clear="none"><br clear="none">The 'fad' languages are very interesting testing grounds for ideas. A <br clear="none">thing like the pipe operator has had many forms, but I'm not sure I'd <br clear="none">call them a fad. They have existed in some form of other as:<br clear="none"><br clear="none">- monads in Haskell and MLs<br clear="none">- pipes in Unix command lines and bash<br clear="none">- Mathematica has // (@ in Wolfram's)<br clear="none">- Some schemes have the (| ... ) syntax<br clear="none">- Clojure has the (-> ... ) threading construct<br clear="none">- Elixir has the |> operator<br clear="none">- method chaining in OO languages can kind of be seen as a way to get <br clear="none"> going there<br clear="none"><br clear="none">It's not like there's 0 prior art and that one is taking incredible <br clear="none">hipster risk by looking at the feasability of such things.<br clear="none"><br clear="none">>Erlang's focus is production, not research. It cannot afford to be a<br clear="none">>fad language. So yes, arguing AGAINST changing it should be a stringent,<br clear="none">>even a knee-jerk reaction to any new suggestions. Erlang works quite well<br clear="none">>in a shocking variety of domains. Anything new threatens that. New<br clear="none">>suggestions absolutely should have to stand up to withering criticism<br clear="none">>over and over until their underlying merit finally wins out.<br clear="none"><br clear="none">Erlang's seat at the junction of research and industry is actually one <br clear="none">of the things that brought me here and let me stay. Saying that Erlang <br clear="none">is not really a research tool is blatantly wrong. There's a crapload of <br clear="none">very interesting papers coming out all the time, of tools at the edge of <br clear="none">research coming out, and they're one of the best thing to ever come out <br clear="none">of this community.<br clear="none"><br clear="none">- Property-based testing has seen major improvements when being used <br clear="none"> under Erlang<br clear="none">- Dialyzer's approach to type analysis is pretty damn interesting and <br clear="none"> comes specifically from that junction between industry and research<br clear="none">- Concuerror and CutEr are other really nifty tools pushing the edge of <br clear="none"> a lot of things (generating functions that break your code? yes <br clear="none"> please!)<br clear="none">- Some of the stuff you see in the seq_trace modules were years ahead of <br clear="none"> what distributed logging would be out there; eventually people caught <br clear="none"> up<br clear="none">- Mnesia once was quite the innovative database<br clear="none">- The process model used in the VM is still quite unlike anything else <br clear="none"> out there<br clear="none"><br clear="none">Granted the language itself is not a research testing ground the way <br clear="none">lisps or MLs have been, but the way it could position itself in the <br clear="none">industry came from using cutting edge technology ("Erlang had this 20 <br clear="none">years ago!") with the care of long-term production engineering in mind.<br clear="none"><br clear="none">If you want to see what a conservative language making conservative <br clear="none">decisions can yield, look at Go. The decisions they made are not <br clear="none">necessarily wrong (though I don't agree with them), but very little in <br clear="none">Go could be said to be innovative. In fact, a lot of the approaches they <br clear="none">have taken 6-7 years ago were already old news almost decades-old to <br clear="none">Erlang developers 10-15 years ago.<br clear="none"><br clear="none">><br clear="none">>Python is in the same boat. "40 posts in a mailing list"... have you<br clear="none">>seen the extreme reluctance Guido takes to adding new features? There is<br clear="none">>a reason. And Python is better for it, still remains consistent, and<br clear="none">>has weathered the language storms to the point that it is emerging as<br clear="none">>the new Java.<br clear="none">><br clear="none">>That didn't happen by adding stuff because it was hip at the moment,<br clear="none">>considered cool in some other language, or whatever. He was serious about<br clear="none">>the idea that "there should be one, preferrably obvious, way to do it".<br clear="none">>Over time it really looks like this has been the more powerful philosophy.<br clear="none">><br clear="none"><br clear="none">Python is a case study of its own. The 2.x to 3.x migration is still not <br clear="none">complete 10 years in for the community. Java is still thriving (I don't <br clear="none">think it has lost users, but the industry has grown around it without <br clear="none">Java necessarily losing much in absolute terms). C# is adding <br clear="none">absolutely interesting stuff that they experiment with in F# before <br clear="none">bringing it back into the main language.<br clear="none"><br clear="none">Languages that never changes are those that die out. Who's thrilled <br clear="none">about using C before C99? But the changes must be worthwhile and <br clear="none">careful.<br clear="none"><br clear="none">>This thread wasn't even about adding a new feature or keeping one out.<br clear="none">>It was about a coding convention Joe ran by us all that sparked a<br clear="none">>conversation which attracted the predictable Elixir straphanger who needed<br clear="none">>to mention that Elixir has pipe syntax and `with` that can do stuff. Neato.<br clear="none">>That's great for Elixir, but a bad fit for Erlang if the only reason is<br clear="none">>to add a "me, too" feature.<br clear="none">><br clear="none"><br clear="none">Have I ever mentioned "we should have it because Elixir does?"<br clear="none"><br clear="none">I'm rather saying "we should possibly consider a form of it based on <br clear="none">observations in other language communities."<br clear="none"><br clear="none">>I'm not against language advancement, but I am against flippant language<br clear="none">>changes. I will play Devil's Advocate for a year, even against features<br clear="none">>I think would personally benefit ME, simply because language changes VERY<br clear="none">>OFTEN have unintended consequences later that are just super hard to<br clear="none">>square after the fact (well, impossible, really). Language design and<br clear="none">>syntax are super tricky subjects once you get outside pure lambda calculus.<br clear="none">>Let's let the exploration bonanza continue -- elsewhere.<br clear="none">><br clear="none">>When it is time to introduce some of these slick features it will be time<br clear="none">>for an Erlang 2 (well, called something else hopefully). I do not believe<br clear="none">>that language is Elixir, though. It has shown us a lot, but its beginning<br clear="none">>to remind me of why Ruby eventually fell apart.<br clear="none">><br clear="none"><br clear="none">Ruby has not yet fallen apart. Mostly, people are migrating away from it <br clear="none">because other languages are now offering a better future than what Ruby <br clear="none">currently offers.<br clear="none"><br clear="none">If anything, a "let's put it in Erlang2" approach, based on current <br clear="none">evidence, is much more likely to be horrible and difficult (modula-3, <br clear="none">python3 or perl6 style) than progressive changes being incorporated into <br clear="none">the language on an ongoing basis.<br clear="none"><br clear="none">I'm not going all in for the syntax changes either; these conversations <br clear="none">are necessary and it's a good thing to be having them.<br clear="none"><br clear="none">But I think you're missing the forest from the trees if you don't think <br clear="none">the experimenting in other languages is not already going full steam <br clear="none">ahead. The question I'm asking is whether it would be time to source the <br clear="none">work of other places yet, if there's a form of it that has so far shown <br clear="none">itself to be adequate. The work has been ongoing for years already.<div class="yqt2672135293" id="yqtfd29439"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">erlang-questions mailing list<br clear="none"><a shape="rect" ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br clear="none"><a shape="rect" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>