[erlang-questions] Time for OTP to be Renamed?

[Garrett Smith]

On Thu, Feb 13, 2014 at 4:42 AM, Anthony Ramine <n.oxyde@REDACTED> wrote:
>
> Le 13 févr. 2014 à 10:51, Garrett Smith <g@REDACTED> a écrit :
>
>> Sigh. This *is* confusing. It just is.
>>
>> Loïc you *cannot* use Erlang without OTP. The VM starts a system,
>> which consists of applications, which are supervisory trees of
>> gen_servers.
>>
>> Supervisors are gen_servers btw.
>>
>> If you think OTP is optional, look at the first two lines of kernel.erl:
>>
>>    -module(kernel).
>>    -behaviour(supervisor).
>>
>> Historically, OTP libraries came after Erlang the language, of course,
>> but this so called OTP "framework" is now endemic to Erlang.
>
> You just proved it's difficult to use Erlang without the stdlib. Erlang is still not OTP.

I didn't say that Erlang is OTP. My point is that treating "OTP" as
something you learn outside of "Erlang" is not helpful.

> In fact, the kernel module isn't even a preloaded module, this means it is not a necessary thing to use Erlang. You could have your own Erlang/E2 if you wanted.

I'm not talking about esoteric details of how Erlang is bootstrapped.
I'm not talking about what you *can* do with the libraries and
tooling. I'm not talking about the language grammar, parsers, tool
chain, etc.

I'm talking about what nearly 100% of all humans use when the use
Erlang, which is a facility for starting a system of OTP applications.
*Practically speaking* OTP is *endemic*.

And my point is that the OTP distinction is confusing and non-helpful,
especially to learners. That you're resorting to technically pedantic
points here I think reinforces what I'm saying.

>> What sucks IMO is that OTP is treated as "advanced" by the community
>> and by book authors. I understand the history of this, but there's a
>> cost: programmers delay learning core Erlang principles of
>> *applications* -- i.e. supervisor trees -- because it's not taught up.
>> It's also incredibly complicated, if you don't use e2.
>>
>> The irony is that *advanced* Erlang programmers can get away
>> programming outside the OTP guard rails. Beginners should not even
>> consider doing this until they understand why OTP works and why they
>> should deviate.
>>
>> e2 helps, a lot.
>
> OTP is a set of building blocks for concurrent and distributed systems.
>
> Concurrency and distribution are advanced topics.

OTP doesn't help with concurrency and distribution. It's there to
organize system start up and process life cycle. It's analogous to
init and monitoring schemes in operating systems (e.g. systemd, runit,
etc.)

If you don't care about how your code is started and managed while
it's running, you might not about "OTP" -- or you might be a guru rock
star. In either case, you're not typical.

> Thus OTP is an advanced topic.
>
>> The whole point of e2 is to simplify the correct use of OTP -- letting
>> programmers *start* with applications, supervisors and gen_servers (in
>> e2 they're called services and tasks -- simple huh). I know it's
>> controversial, but it's controversial to those who have been teaching
>> Erlang while this stuff was being baked. I don't run into new learners
>> who object to starting with OTP using e2 (though maybe they're just
>> being polite -- if you're out there and had problems learning with e2,
>> please drop me a line, or yell at me here).
>
> e2 is a leaky abstraction which you need to deviate from when you need more complex stuff; let's not add an infinity of layers on top of OTP.

All abstractions leak. And even with that, e2 actually is pretty tight.

The *only* time I don't use e2 is when I don't want to introduce it as
a library dependency (e.g. within another small library like a
database driver, etc)

Have you used e2? Did you run into a specific case that e2_process or
e2_task didn't accommodate?

And *one thin layer* layer on top of on an interface that is begging
to be simplified is certainly not an infinity.

>> I agree wholeheartedly with Pieter. It's just Erlang. Keeping the term
>> OTP is a historic vestige. We're used to it, but it's a dead weight
>> that adds only confusion.
>
> Erlang itself is dead weight to most in the industry, does that mean we should forgo Erlang altogether?
>
>> The Ruby / Rails comparison is not accurate. It's more like Rails 1.0
>> / Rails 2.0.
>
> I have no idea how you would find this accurate.
>
>> Sadly though, I just don't see "OTP" going away because there's a
>> trickle of noise from this list :|
>
> How do you know there isn't a silent majority who just doesn't care or wouldn't like the OTP team to spend time trying to rewrite history? That sounds quite a dismissal of the opposing opinion in this debate. In fact,  I have to admit I wouldn't have replied if not for that sentence.

I haven't seen a call for rewriting history.

The call is to stop using "OTP" as a meaningful term in the context of
Erlang. You and Loïc have accurately pointed out that it's *possible*
to separate a couple layers within Erlang that coincide with this
Erlang/OTP division. But it's not *practical* and the practice of
treating OTP compliance as something-to-learn-later is bad for Erlang,
IMO.

I'd like to see an effort to simplify the code and process needed to
write OTP compliant code. e2 is I think a reasonable first attempt at
that. I would offer it as input to the process.

>> I make videos to cope.
>
> I give value to historic facts and terminology to cope.

But as long as you cope. It's the most important thing.

Garrett