[erlang-questions] Must and May convention
Thu Sep 28 17:59:16 CEST 2017
On 2017年09月28日 木曜日 11:33:29 Fred Hebert wrote:
> I am able to get along fine without it, but if working without a similar
> construct requires 40 posts in a mailing list to make sure other people
> get a solution or pattern they are comfortable with when the operator is
> *not* available, then maybe there's a need to look at ways to improve
> the current state of things.
I get your point, but this is a fantastic mischaracterization of what is
So what IS actually happening?
We have an explosion of fad languages that keep adding sexy syntax all
over the place. People get sort of used to a few of them and then get
surprised when something new (like matching) is central to this new one
they're not used to, but feel like things are somehow wrong if one they
were expecting (like a composition operator, or objects, or whatever) is
What is happening in that fantabulous language space?
The languages are dying out, suffocating under their own weight and
semantic confusion -- leading to the sudden emergence of new sexy
This is actually AWESOME, overall, for the future of programming.
Eventually we are definitely going to figure out on something that is
just flat out Right for a wide variety of general cases.
But it is actually REALLY BAD for maintenance, writing production code,
onboarding new people who need to be productive, and the stability of
languages overall. Languages don't really evolve -- they become new,
subtly incompatible languages.
Erlang's focus is production, not research. It cannot afford to be a
fad language. So yes, arguing AGAINST changing it should be a stringent,
even a knee-jerk reaction to any new suggestions. Erlang works quite well
in a shocking variety of domains. Anything new threatens that. New
suggestions absolutely should have to stand up to withering criticism
over and over until their underlying merit finally wins out.
Python is in the same boat. "40 posts in a mailing list"... have you
seen the extreme reluctance Guido takes to adding new features? There is
a reason. And Python is better for it, still remains consistent, and
has weathered the language storms to the point that it is emerging as
the new Java.
That didn't happen by adding stuff because it was hip at the moment,
considered cool in some other language, or whatever. He was serious about
the idea that "there should be one, preferrably obvious, way to do it".
Over time it really looks like this has been the more powerful philosophy.
This thread wasn't even about adding a new feature or keeping one out.
It was about a coding convention Joe ran by us all that sparked a
conversation which attracted the predictable Elixir straphanger who needed
to mention that Elixir has pipe syntax and `with` that can do stuff. Neato.
That's great for Elixir, but a bad fit for Erlang if the only reason is
to add a "me, too" feature.
I'm not against language advancement, but I am against flippant language
changes. I will play Devil's Advocate for a year, even against features
I think would personally benefit ME, simply because language changes VERY
OFTEN have unintended consequences later that are just super hard to
square after the fact (well, impossible, really). Language design and
syntax are super tricky subjects once you get outside pure lambda calculus.
Let's let the exploration bonanza continue -- elsewhere.
When it is time to introduce some of these slick features it will be time
for an Erlang 2 (well, called something else hopefully). I do not believe
that language is Elixir, though. It has shown us a lot, but its beginning
to remind me of why Ruby eventually fell apart.
More information about the erlang-questions