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

[Fred Hebert]

On 02/13, Garrett Smith wrote:
> 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.
> 

To me that's often a required step. Plenty of programmers do not know or
aren't comfortable with:

- Pattern matching
- Recursion
- Higher Order Functions
- Anonymous functions
- Principles of concurrency
- Principles of distribution
- Prolog-like Syntax
- Expression-based conditionals (case/if)
- Single Assignment
- Immutability (and the lack for while and for loops)
- Not using objects

And they can furthermore come with baggage regarding algorithms and data
structures (usually mutable!) and code structure that makes it really
hard to adapt.

Picking to go OTP first, I believe, makes the implicit assumption that
the reader or audience will be familiar with some of the things used in
Erlang.

If you don't make these assumptions, starting with OTP frankly reminds
me of Java's Hello World to a first-time programmer:

    public class HelloWorld {
       public static void main(String[] args) {
             System.out.println("Hello, World");
       }
    }

New concepts to a new programmer may include: public, class, static,
void, main function, String[] type, Function call syntax.

At this point, for a reader unfamiliar with these terms, you either have
to handwave it away and say "oh we'll see this later" or "you don't have
the qualifications required for this text", in which case, the person
*will* have to explore these concepts, either later in the text, or
without you.

I'm taking this to heart because I made the decision to show stuff from
the ground up in LYSE for this specific reason: people who are
unfamiliar with functional concepts may get one hell of an overload if
they get to learn them while learning Prolog-y syntax, Concurrency, and
a general development framework on top of it.

It doesn't mean it's impossible or even a bad idea, but it's freaking
harder to write for, and for me as a reader, to understand (my decisions
are often validated by how I'd use my own work here, which is subject to
bias, but yeah).

Oh and I also like to take the approach where every feature is
introduced as solving a specific problem -- that's how I try to get to
reader to see it as important or worth looking into. How do you sell the
idea of OTP without first encountering the problems it solves? Things
write themselves more or less naturally when you start with mailboxes
and say "hot damn this gets repeated a lot."

There's a lot of validity in wanting to show people how to wrap their
code into a functioning application, into libraries, and into
supervision trees. It would probably save a lot of bad code or
half-wrapped applications that discover OTP too late and then need a
rewrite.

I however have a hard time expecting to see the benefits when the target
audience possibly doesn't know how to write a list lookup function
recursively with the use of pattern matching in the first place,
however. Maybe when the general public is more familiar with functional
style, it will be easier to jump into OTP early.

Until then, OTP *is* advanced for a large part of the population who
doesn't have the functional prerequisites to feel at home in a language
like Erlang at *any* level.

Regards,
Fred.