[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

[Michael Malter]

That's right. I meant small.

And yes believe it or not, the first (second maybe) marketing campaign for
Java was titled "Java is simple". :)

Le lun. 25 avr. 2022 à 17:45, Austin Ziegler <halostatue@REDACTED> a
écrit :

> On Mon, Apr 25, 2022 at 11:27 AM Michael Malter <airlangue@REDACTED>
> wrote:
>
>> Well I would rather let Joe rest in peace but the reference is probably
>> helpful there.
>>
>> Erlang is simple. I mean, that's how Joe saw it. He expressed it multiple
>> times.
>>
>
> Simple is in the eye of the beholder. I would disagree with the assessment
> that Erlang is simple, but From a Certain Point of View, it is, sure. Is it
> simpler than Elixir? In some ways, yes. In other ways, no. If you’re trying
> to say that Erlang is a *small* language, then I’d mostly agree. So is
> Elixir, though. From certain points of view, Elixir is much easier to
> apprehend than Erlang, because Erlang is more sparse than Elixir. As a
> language.
>
> That said, it took me a *long* time to understand `=:=` because it’s a
> complex, compound sigil (not used _that_ frequently) that I’ve never seen
> in any other language (and I know quite a few). To _me_, `^Value -> …` is
> clearer than `NewValue when Value =:= NewValue`. But that’s me.
>
>
>> Do you remember the time when that was the Java motto ? Look at Java now.
>>
>
> I never remember such a day. Granted, it got much worse after the
> introduction of J2EE and all that crap, but I never remember Java being
> "simple".
>
>
>> Is it so hard to understand what we are saying ? For once it's pretty
>> clear and without many diverging opinions.
>>
>
> Except that there *are* numerous diverging opinions. They just tend to be
> drowned out by louder people who can’t seem to express their opposition in
> the simple, clear terms that you and Loïc have, and instead are making
> purely emotional expressions.
>
> - it's not sufficiently useful to warrant another language features (you
>> know, less is more)
>> - it's yet another sigil and we hate them.
>>
>
> The former is arguable, and I’ve seen little in any of the threads about
> this EEP to suggest that this is the case. The latter is a matter of taste,
> but it’s also a legitimate concern. New sigils shouldn’t be added without
> good reason. I’ve seen such discussions in Elixir and Ruby language
> discussions, and sometimes a new sigil gets added (`&.` and `->()` in Ruby;
> I like the former, hate the latter, although I use it).
>
> Not addressed in the original EEP (probably because it wasn’t originally
> considered) is whether expressing pinning might improve the compiler’s
> ability to generate better code. It’s been raised on the forum though, and
> it should be considered. If nothing else, it starts to indicate that there
> may be more use than simply avoiding guard clauses (which IMO is worthy in
> and of itself).
>
> -a
>
> Le lun. 25 avr. 2022 à 17:14, Austin Ziegler <halostatue@REDACTED> a
>> écrit :
>>
>>> On Mon, Apr 25, 2022 at 10:58 AM Stanislav Ledenev <s.ledenev@REDACTED>
>>> wrote:
>>>
>>>> One question - why? Just because we can?
>>>> Erlang is doomed, Sorry Joe, we f**d things up.
>>>>
>>>
>>> I really can’t help but laugh at over the top reactions like this and
>>> those who can’t help but bash Elixir because they don’t like the syntax.
>>>
>>> What if this syntax (or some other syntax) helps the compiler generate
>>> better (safer, faster, *whatever*) code? How would anyone know unless
>>> it gets tried? Why would anyone want to try it when they know that a
>>> certain vocal subset of the community are going to be pitching embarrassing
>>> fits over it?
>>>
>>> If this is introduced in OTP 26, then stop upgrading. Seriously. Stay on
>>> OTP 25 or before. But seriously, stop acting like children about this and
>>> saying that things are fucked up (because they’re not; you just don’t like
>>> this because you don’t like it). The only *real* objection that I’ve
>>> seen that makes sense to me is from Loïc, which is that it might be better
>>> to enable *annotations*, even if the only annotation initially
>>> available is for pinning. (My personal feeling on the annotation concept is
>>> that `^pin Variable` doesn’t feel right to me, but maybe `^pin:Variable` or
>>> `^pin{Variable}` or `^{pin}Variable` or something else, although more
>>> sigil-y, would be clearer.
>>>
>>> I mostly use Elixir, but often read Erlang codebases. On the Elixir core
>>> mailing list, there are frequent redirects to approach something as a
>>> possible PR to Erlang/OTP because it’s something that should benefit all
>>> BEAM languages.
>>>
>>> Telemetry started as an Elixir library, but was quickly changed to a
>>> pure Erlang approach because it makes more sense to be something that all
>>> BEAM languages can use.
>>>
>>> Elixir has — and I suspect both LFE and Gleam both have — *enhanced *the
>>> BEAM through wider exposure, code contributions, and other contributions.
>>> If you can’t argue a feature request like in this EEP on its merits (or
>>> lack thereof) without trying to bash Elixir, then maybe you don’t actually
>>> have an argument, but an emotional outburst, and should just *discard* your
>>> rant after writing it.
>>>
>>> -a
>>> --
>>> Austin Ziegler • halostatue@REDACTED • austin@REDACTED
>>> http://www.halostatue.ca/ • http://twitter.com/halostatue
>>>
>>
>
> --
> Austin Ziegler • halostatue@REDACTED • austin@REDACTED
> http://www.halostatue.ca/ • http://twitter.com/halostatue
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220425/0fef3ed0/attachment.htm>