[erlang-questions] Must and May convention
Thu Sep 28 18:32:48 CEST 2017
On 09/29, zxq9 wrote:
>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
I'm not necessarily speaking of this specific thread. This conversation
is neither the first nor the last one about this. At work I've recetly
trained a team of 12 people into using Erlang and the questions about
the patterns in this thread have been had there as well. And similarly
for questions from the previous threads -- whether exceptions are the
right tool when it comes to validation.
>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 'fad' languages are very interesting testing grounds for ideas. A
thing like the pipe operator has had many forms, but I'm not sure I'd
call them a fad. They have existed in some form of other as:
- monads in Haskell and MLs
- pipes in Unix command lines and bash
- Mathematica has // (@ in Wolfram's)
- Some schemes have the (| ... ) syntax
- Clojure has the (-> ... ) threading construct
- Elixir has the |> operator
- method chaining in OO languages can kind of be seen as a way to get
It's not like there's 0 prior art and that one is taking incredible
hipster risk by looking at the feasability of such things.
>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.
Erlang's seat at the junction of research and industry is actually one
of the things that brought me here and let me stay. Saying that Erlang
is not really a research tool is blatantly wrong. There's a crapload of
very interesting papers coming out all the time, of tools at the edge of
research coming out, and they're one of the best thing to ever come out
of this community.
- Property-based testing has seen major improvements when being used
- Dialyzer's approach to type analysis is pretty damn interesting and
comes specifically from that junction between industry and research
- Concuerror and CutEr are other really nifty tools pushing the edge of
a lot of things (generating functions that break your code? yes
- Some of the stuff you see in the seq_trace modules were years ahead of
what distributed logging would be out there; eventually people caught
- Mnesia once was quite the innovative database
- The process model used in the VM is still quite unlike anything else
Granted the language itself is not a research testing ground the way
lisps or MLs have been, but the way it could position itself in the
industry came from using cutting edge technology ("Erlang had this 20
years ago!") with the care of long-term production engineering in mind.
If you want to see what a conservative language making conservative
decisions can yield, look at Go. The decisions they made are not
necessarily wrong (though I don't agree with them), but very little in
Go could be said to be innovative. In fact, a lot of the approaches they
have taken 6-7 years ago were already old news almost decades-old to
Erlang developers 10-15 years ago.
>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.
Python is a case study of its own. The 2.x to 3.x migration is still not
complete 10 years in for the community. Java is still thriving (I don't
think it has lost users, but the industry has grown around it without
Java necessarily losing much in absolute terms). C# is adding
absolutely interesting stuff that they experiment with in F# before
bringing it back into the main language.
Languages that never changes are those that die out. Who's thrilled
about using C before C99? But the changes must be worthwhile and
>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.
Have I ever mentioned "we should have it because Elixir does?"
I'm rather saying "we should possibly consider a form of it based on
observations in other language communities."
>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.
Ruby has not yet fallen apart. Mostly, people are migrating away from it
because other languages are now offering a better future than what Ruby
If anything, a "let's put it in Erlang2" approach, based on current
evidence, is much more likely to be horrible and difficult (modula-3,
python3 or perl6 style) than progressive changes being incorporated into
the language on an ongoing basis.
I'm not going all in for the syntax changes either; these conversations
are necessary and it's a good thing to be having them.
But I think you're missing the forest from the trees if you don't think
the experimenting in other languages is not already going full steam
ahead. The question I'm asking is whether it would be time to source the
work of other places yet, if there's a form of it that has so far shown
itself to be adequate. The work has been ongoing for years already.
More information about the erlang-questions