<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tors 28 jan. 2021 kl 11:20 skrev Valentin Micic <<a href="mailto:v@micic.co.za">v@micic.co.za</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">Since you have call upon businesses “who relay on Erlang”, and given the fact that my business has relied on Erlang for  better part of this century (last 18 years to be specific),  I would have to offer my opinion on this — you are welcome to ignore it, but I feel obliged to correct you here.<br>
<br>
Even if one ignores a “straw-man” nature of the first portion of your argument — if you do not want to end up like COBOL, you should do what I say; it really does not follow that leaving out this “pinning operator ^” will condemn Erlang to the ashes of history.<br></blockquote><div><br></div><div>You are absolutely correct there; these are two different things. My reply above was about the general statement that if one feels the need to take a language in a new direction, one should start on a new language instead. Erlang can and will go on with or without this particular change. The question is where we can go. If we don't find ways to improve - in a fairly big way - we will keep losing traction.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As a person with somewhat long memory,  may I suggest it was not the syntax that condemn COBOL to “eternal maintenance”.<br>
Rather, it was a demise of main-frame that did that. No amount of advancement of the syntax (COBOL 2014 anyone?)  could have prevented it.<br></blockquote><div><br></div><div>I'm sure it was not the syntax per se. Syntax details in itself (like keyword length, punctuation rules and so on) is not so interesting as what you can and cannot express in the syntax, and whether it's readable (because we spend so much more time reading and trying to understand code). Many things would have had to change, and quickly, for Cobol to keep its place, since the whole language model was probably too tightly coupled to the mainframe style. I don't know any details about that.</div><div><br></div><div>There are probably way too many weird corner cases in an old imperative language like Cobol, and particularly given the tooling of the 70s and 80s, to automatically migrate codebases to newer forms of the language, step by step. Had that not been the case, maybe it could have been kept modern while phasing out obsolete stuff. (Just adding new features and keeping support for the old stuff forever does not make a good language in the long run.)</div><div><br></div><div>Erlang is different - it's mostly side effect free, with a simple set of data types - and I think we have an opportunity of making changes while bringing the existing code with us, not leaving features in infinite-compatibility mode (as in the cluttered later Cobol and C++ versions) but actually dropping them and updating the code correspondingly, without risking new errors by doing the changes manually (and for a huge code base, some changes are just not feasible to do by hand). That is my vision, anyhow.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1) Appeal from authority — Well, this is supported by WhatsApp team and otherwise prominent people;<br></blockquote><div><br></div><div>But the argument is not from authority, but from experience - companies with large Erlang codebases have known pain points that they feel the need to address somehow. If they don't, management will always be pushing to switch to other languages for new projects, so development can go faster and they can find programmers to work on the code. They sometimes even call for a big rewrite, even if we know how that usually ends up. That's just the reality.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) Composition fallacy — if it is good for WhatsApp, it must be good for everyone;<br></blockquote><div><br></div><div>That's not something I have claimed, though. I have agreed that for a lot of simple code, ^-annotations will look superfluous. What's good for WhatsApp is more likely to be good for other companies with large codebases, like Klarna (where I worked for many years), but even then it's not for certain, if it's something that addresses only a problem for the "huge instant messaging service". In the case of ^-annotations, and probably scoping in general, I think we've seen that it's not specific to WhatsApp, but at the same time that it's not so important for smaller codebases. The question is whether those with small codebases can agree to such a change on the merit that it's not too annoying either and occasionally solves a problem for them too.</div><div><br></div><div>    /Richard</div><div><br></div></div></div>