[erlang-questions] Must and May convention

[Vans S]

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

The problem with python 3 is code cannot be run on a python 2 interpreter.

They royally messed this up by not having backwards compatibility and hence why the transition is 
so long. OTP seems very good with depreciation and ensuring backwards compatibility.

I welcome a fully backwards compatible Erlang2, and Erlang3/4/5, as long as we don't have
another running Erlang2 from Erlang1 crisis (*cough* elixir).

If at the end of the day Erlang2 will generate erlang1 compatible beam files everything should be well,
then just pick a syntax/language you like (erlang2/3/4/5/9000), compile the beams, run them on BEAM.

The big problem with why elixir kind of "poisoned" the community in regards to having spinoff languages 
using beam is because they messed up the elixir compiler.  1-2 features ruined the whole thing and
made it a royal mess.  Those 2 features are multiple modules per file, and macros.  The cost of
having these 2 features which are rarely used is very high, to the point elixir cant even hotload properly 
without fully purging modules (crashes during hotload if you call into a purged module at exact time elixir is
hotloading).


 

    On Thursday, September 28, 2017 12:33 PM, Fred Hebert <mononcqc@REDACTED> wrote:
 

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

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

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 
  under Erlang
- 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 
  please!)
- 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 
  up
- Mnesia once was quite the innovative database
- The process model used in the VM is still quite unlike anything else 
  out there

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

>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 
currently offers.

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.


_______________________________________________
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/1e0a3056/attachment.htm>