New EEP draft: Pinning operator ^ in patterns
Thu Jan 28 15:38:10 CET 2021
> 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.
Are you not making the assumption here that this pinning operator is an improvement that Erlang desperately needs (e.g. to not die)? You are right, Erlang has to find ways to improve, but is the pinning operator that, an improvement? I am genuinely asking as I do not see it as an improvement, but I do not exclude the possibility of me being wrong. I saw code snippets on this mailing list that use the pinning operator, and all I can say is that it is confusing _to me_. Perhaps it is not confusing to other people, but to me they are (perhaps they would not be after some time, but I am not sure that this is the direction I would want to go), whereas if Erlang was going to improve without the pinning operator (or similar changes in the syntax) then it would remain understandable _to me_ and lovable by _me_, because there are many different ways to improve, it does not have to be the case of "either we add the pinning operator, or Erlang will not improve, and possibly never improve", because that is how I read that quote above with the context in which it was embedded. If syntax is changed in such a way that it hurts the core concepts of the language for what people love Erlang, then I have to say no to it, but I am just a newbie, so take my words with a pinch of salt.
To reiterate a couple of things:
1) every code snippet that contained the pinning operator have seemed odd or confusing to me, but I may have misunderstood the proposal or the pinning operator. If this is going to add shadowing or somehow mess with single assignment which is a crucial part of Erlang and would allow the same variables (or variables with the same name) to be used in one way or another, then it is still a no from me. If it does not do that, then I should probably go back and read the initial proposal, because then I most likely misunderstood it.
2) not adding the pinning operator does not mean that Erlang will not improve in a multitude of other ways and that it will die. You are right, however, about that the language has to improve in some ways to keep up, but some things are better left alone, such as the syntax, in my opinion. I am sure people want to improve the language, but perhaps not by adding the pinning operator (if it indeed is an improvement).
I agree with responses such as (this particular one is by zxq9) this:
> Changes that move directly against one of the most basic core concepts of the language are not only a disservice to existing codebases written with those core concepts in mind, but also leaves homeless users who are attracted to Erlang specifically because of those core concepts.
To this I would like to add that it is not just about existing codebases to me. It is new ones as well, because "who are attracted to Erlang specifically because of those core concepts." is referring to people like me, and I do write new projects in it.
In any case: does this change move against it or not? If not, then I, and perhaps others have misunderstood something. If it does, then I will keep my stance which is: would rather not see it in the language, and I do not consider it an improvement. This does not exclude other improvements of the language of course, and it does not have to die. In fact, some parts may be stable enough that they only require fixing bugs and improving performance.
After some responses I feel like I have to add that I do not consider my disagreement to the pinning operator personal, nor do I consider my responses to your quotes personal, I just simply want some clarifications so I could understand it better. It is not an attack on your person in any way, and I hope it is not interpreted as such.
Thank you for your answer in advance. If some of what I said is unclear or wrong, please let me know, because I believe it is important that we understand each other and that we do not talk over each other.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, January 28, 2021 12:34 PM, Richard Carlsson <carlsson.richard@REDACTED> wrote:
> Den tors 28 jan. 2021 kl 11:20 skrev Valentin Micic <v@REDACTED>:
>> 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.
>> 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.
> 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.
>> As a person with somewhat long memory, may I suggest it was not the syntax that condemn COBOL to “eternal maintenance”.
>> 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.
> 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.
> 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.)
> 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.
>> 1) Appeal from authority — Well, this is supported by WhatsApp team and otherwise prominent people;
> 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.
>> 2) Composition fallacy — if it is good for WhatsApp, it must be good for everyone;
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions