[erlang-questions] Must and May convention

[Vans S]

> I agree - there are many fun languages on the horizon.
>
> Red, Nim, Crystal, Eve, Pony

This always leads me to think we should be writing engines, not languages.  A language should just be a syntax that compiles into an 
abstract form.  Too many of these new languages keep repeating the same things over and over in slightly different ways when it comes
to the internals.

> When I'm writing Elixir I keep thinking - "I wish I could do that in Erlang"
> Pipes are nice - we talked about them.
>
> I also like string interpolation
>
>    io:format("Hello ~s it's ~s today",[Person,Weather])
>
> Sucks - the Variables are too far away from the formatting characters
> so
>
>  io:format("Hello #{Person} it's #{Raining} today")
>
> would be much nicer

I really like the ideas behind this but working with the yrl seems to be an undocumented dark art, and very time consuming to 
learn.  There is so many things I would like to be able to do and to have the code compile to the same/functionally similar abstract form.

my_fun(atom, Map=#{bitfield_set=> _}) ->
        Value = maps:get(key, Map),
        Value2 = maps:get(key2, Map, undefined),
        Value3 = maps:get(key4, maps:get(key3, Map, #{}), undefined),
        List = io:format("the atom as a binary is ~p ~p", [atom, Value]),
        unicode:characters_to_binary(List).

    VS

fun my_fun(atom, Map=#{bitfield_set}) ->
    Value = Map[key]
    Value2 = Map[key2, undefined]
    Value3 = Map[key3][key4]
    "the atom as a binary is #{atom} #{Value}"
end 

    On Thursday, September 28, 2017 2:21 PM, Joe Armstrong <erlang@REDACTED> wrote:
 

 On Thu, Sep 28, 2017 at 5:59 PM, 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.

I agree - years ago I argued against backwards compatibility - but
that was in the
days when if you wanted to change the language and break old code
we only had a few users and they were used to us breaking things.

The first doubts I had came a few years later - we were growing and
I wanted to break the system again by removing stuff that we should
never have put it.

I had an argument with a guy - over this.

"But we've tested the code"

"So change it and test again"

"Do you realise how difficult a test is?"

"No"

"We have to book the test facility 3-4 months in advance, they have to setup
it up - this takes 3-4 days (if we're lucky) then we run the tests a few hours
and they tear down the test setup - there's a lot of hardware involved."

The test facility had to booked months in advance and the tests cost a lot.
Full systems test are far more expensive that software testing .. .

Fast forward 30 years.

Amazing I can still compile and run erlang code I wrote 30 years ago - mostly
it works sometimes it needs very small changes.

When I run my old C (which worked) I am hit by a tsnami of warnings and errors.

There's a problem with software - really when we add something to a language.
We could have removed records when we added maps but this cause howls
of protest.

I think if you want to make a new dialect of Erlang (and it is a new
dialect and not a new language) then find - go ahead.

I while back I made erl2 to experiment with some changes to Erlang.
(see https://github.com/joearms/erl2)

X.erl2 files are transpiled into X.erl files -- this messes with and breaks
nothing.

If anybody wants to fix a bug they have to delve into erl2 and there is
no tooling emacs mode screws up, dialyzer etc cannot work on erl2
and so on.

Elixir is sufficiently different from Erlang that it superficially looks like
a different language - the funny thing (to me) is that this relative small
change in syntax turns out to turn what is perceived as "scary"
into something that is perceived as "familiar".

When I'm writing Elixir I keep thinking - "I wish I could do that in Erlang"
Pipes are nice - we talked about them.

I also like string interpolation

    io:format("Hello ~s it's ~s today",[Person,Weather])

 Sucks - the Variables are too far away from the formatting characters
so

  io:format("Hello #{Person} it's #{Raining} today")

would be much nicer


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

I agree - there are many fun languages on the horizon.

Red, Nim, Crystal, Eve, Pony

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

I'm not so sure - PHP is very popular - Visual Basic was so good
that Microsoft had to ruin it - Hypercard was so good that it is no longer
available. Programming in Borland turbo graphics was so fast and easy
that massive IDEs had to be invented.

Simple languages that encourage clear and correct code and do
no need armies of consultants to maintain into the future
are not very popular.

It's the "Nobody got sacked for using Microsoft" phenomena - there is
job security in using mainstream languages, and job security in writing and
fixing buggy code.

/Joe


>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
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/9cf18c6c/attachment.htm>