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

[Richard A. O'Keefe]

If you just want to change what the initials stand for,
"Operations, Tools, and Packages" is a pretty fair summary
of what's in there.

The other issues Fred Herbert has raised seem to me to be
important ones (and not entirely unrelated to the NZ flag
debate either).
> 
> - The syntax is unfamiliar (or ugly)

COBOL. Fortran. BASIC. Algol 60. Algol 68. Eiffel.
Lisp. APL. Occam. SML. C#.  Ada.  Not a lot of syntax
in common.  (Not even 1+1.)  *Good* programmers can
see through syntax.  Beginners need to learn how to
do this.

It has been argued -- by someone who had never heard of
Erlang -- that a language with "familiar" syntax will
still be a basically sequential language, encouraging
us to think in ways that don't fit the multicore era.
(Which was in the future when he wrote.)

Switching from Lispy syntax to C-ish syntax did not
make Dyland more popular.  Switching from 16'F00 to
0xF00 doesn't seem to have made Prolog more popular.

I think that (almost) having a popular syntax from
day 1 helps a *new* language gain popularity; if
there is evidence that making the syntax of an
existing language more familiar helps it the language
become more popular I'd like to see it.

To an Ada programmer, Fortran 90 was a lot more
comfortable than Fortran 77.  That didn't make me
want to change back...

The best I can say in favour of Erlang syntax is that
there's not really enough of it to be *too* horrible.
So what?  How many of us are married to supermodels?
It's the semantics that really matters.

I recently heard about a commercial plugin for Eclipse
that detects a range of concurrency errors in Java.  I
looked at the examples, and didn't notice anything that
any sane Erlang programmer would do even by accident.
It's the semantics that really matters.

Anyone who isn't willing to look past the syntax should
be set to maintaining Visual Basic.

> - It's difficult to work with single assignment, recursion, immutable
>  algorithms (most of your algorithm books that rely on arrays with O(1)
>  access to work fine are no longer going to be trivial to translate!
>  That's huge!)

This is true.
Does anyone know what fraction of an Erlang programmer's time
is actually spent writing data structures?

I wonder if the Erlang documentation site could have
a page dedicated to data structures provided by the library
and by other well-known sites like Jungerl.
Will maps make much of a difference here?

(There was an introduction-to-programming book written in
French that I read many years ago.  It used Algol 68, and
got at least 2/3 of the way before mentioning assignment.)

I recently had an e-mail discussion with someone who said he
had been writing Prolog for 20 years, but who regarded
higher-order programming as "advanced".  I pointed out that
the only "mainstream" languages (other than Fortran and COBOL
of course, OO though they are) that _don't_ support higher-
order programming are Java (but it's _definitely_ in Java 8)
and C (which _does_ have anonymous functions in Mac OS X and
iOS).  It turns out that even Visual Basic has 'em.

Is it realistic to teach people list processing
with list comprehensions *before* you teach recursion?
I've never tried, but maybe that could work.

> - The tooling (rebar, relx, etc.) isn't up to par with other languages,
>  even if it keeps getting better.
> - Lack of IDEs (that was your prime concern when you joined these lists)

I bet the people who worked on Distel and ErlIDE,
amongst others, feel sick every time someone says there
is a lack of IDEs.

> - Fighting the idea that "it will be hard to hire Erlang developers" to
>  make it enter and stay in the enterprise.

Gabriel and others have argued that the idea is mistaken,
but it is certainly real.
> 
> Now if you please, I'll go back to spending my lunch time working on an
> post-scripted chapter to the LYSE site introducing maps to people.

Perhaps someone could contribute an ErlIDE chapter too.
Me, I've never been able to get hello world going with
Eclipse, so I can't write it.  But I'd love to read it.