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

[Aaron France]

This whole thread is a waste of time. What the hell has happened to
this list?

On Thu, Feb 13, 2014 at 11:42:09AM +0100, Anthony Ramine wrote:
> Hello,
> 
> Replied inline.
> 
> Regards,
> 
> -- 
> Anthony Ramine
> 
> 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.
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > 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 make videos to cope.
> 
> I give value to historic facts and terminology to cope.
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140213/ce04cdfd/attachment.bin>