[erlang-questions] Must and May convention

[Vans S]

>> Adding temporary variables is also nice because you>can print them when things go wrong.
> Elixir has IO.inspect which you can use to tap into the middle of a pipe chain to output the intermediate state. (A form of the Kestrel combinator iirc)
This is exactly my biggest problem with elixirs pipe operator and why I do not feel comfortable using it except inthe most safest of cases.  It makes debugging and tracking errors more awkward, and I often found myself breakinglong pipes into temporary variables so I can inspect them. Multiple assignment kind of remedies the need for pipes.
Users = lists:filter(fun/1, Users)Users = lists:map(fun/1, Users)Users = lists:sort(fun/1, Users)
> So the |> pipe operator is not really perfect in elixir:
> - it is strict with regards to position of the arguments> - it obscures the original number of arguments to a function (hello >   tracing)> - it may compose or nest funny in some cases or other constructs> - it is limited in what it can do (see my previous post in this thread)> - it brings the language down a tricky avenue since other similar >   control flow constructs would need to add more special operators with >   new semantics> - other language features may be equivalent to it already
Agree with most of this and want to add you can use anon functionsto remove the strictness of position of args
"5" = %{key: 5}   |> (&(:maps.get(:key, &1))).()   |> Integer.to_string
Piping to &:maps.get(:key, &1) does not work and gives a deprecation warningsso it leaves me to wonder if it worked before, as its much simpler to read.
Going back to
{ok, Bin} | {error, Reason} = File:read("my_file") VSBin | throw/1 = File:read!("my_file")
After a good nights sleep I think I will side with this behavior:
If we were to write:
{ok, Bin} = File:read("my_file") 
we should instead write: 
Bin = File:read!("my_file")  OR Bin = MUST File.read("my_file")  OR..you get the idea.

Because if File:read/1 returns an error we crash anyways due to our pattern match, andthe only element in position 1 would be 'ok'.
If we were to write case File:read("myfile") do, we should get the {ok, Bin}.
Now the 3rd case is where we store a local variable to case on, 
Res = File:read("my_file")case Res of  ..end
To support all 3+ cases we need full control.  For example sometimes I dont like that:global.register_name crashes instead of returning me a error tuple. Other times I welcomethe crash. 

    On Thursday, September 28, 2017 11:59 AM, zxq9 <zxq9@REDACTED> 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
happening.

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
missing.

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
languages.

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.

-Craig
_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions


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