New EEP draft: Pinning operator ^ in patterns

[Richard Carlsson]

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.

    /Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210128/d54d7051/attachment.htm>