
An Open Letter to the Erlang Beginner (or Onlooker) - icey
http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlooker.html
======
johnbender
I think what most of the pro-erlang articles are actually extolling is the VM
and not the language itself. The last 3 sections of the article are purely
about VM features.

BEAM is an incredible piece of work, you can keep the syntax/string handling.

------
billmcneale
Wow, this is an endless list of apologetic statements trying to paper over
Erlang's many deficiencies.

"Your first contact will suck but it's not Erlang's fault, it's yours".

Way to motivate.

~~~
mononcqc
Bicycles have training wheels to get you going. Erlang doesn't. It might be
hard and require effort.

I don't know how you learn new things, but it's generally taking me lots of
effort: math, sports, music, etc. They're all hard when you first begin.

I remember I couldn't ever do anything good on a bass guitar (I started
learning with a terrible sense of rhythm, not being able to clap on a 4/4
beat). I thought that music was just too hard, that the notation was too
complex and obtuse for the sake of it, that improvising and jamming took some
natural skill to get. It doesn't. All it takes is work, lots of it. It's hard
because it's different and not something you pick up easily without prior
experience. And even once I learned how to play bass (and have been for years
now), I can't play drums for shit because it requires an entirely different
way to think about music, notation and synchronism. You have to get in a
different mindset when you switch instruments, or even just bands.

As for sports, mastery takes years. Of course someone in a good physical
condition will pick up some of them with more ease than someone not used to
many sports, but if you're a trained ice hockey player, the skillset you learn
won't apply with the same ease for baseball or basketball when compared to
roller hockey or field hockey. You have to go back to some basics. Re-learn
how to position yourself, new strategies, discover muscles you hadn't trained
before.

I see learning new programming languages as something somewhat related --
Languages can do their best to be friendly, but when the concepts behind them
just vary wildly (see Prolog vs. C), you'll likely hit a wall. And it will not
be the language's fault, but a question of you working hard enough to grasp
it. Many languages have similar concepts and could be compared to switching
from Bass Guitar to a cello, or from football to flag football. Python and
Ruby have different syntaxes, but switching from one to the other is often a
question of details. Even going back and forth with PHP is a similar thing.
Going from Scheme to Common Lisp isn't as big of a leap as going from Prolog
to C. I do believe Erlang (and many functional languages) fit this concept.

If you've never worked with them before, you'll be surprised by persistent
data structures, the absence of O(1) arrays, message passing semantics, share-
nothing ideas, lack of global data, an environment without main loops (or any
kind of loops), different ways to handle exceptions, a specific way to package
and write applications, lack of namespaces, new syntax, atoms, pattern
matching, linked-lists as strings, bit syntax, etc. Of course the first
contact will suck if many of these concepts are foreign -- you have to learn
from scratch when you likely were very proficient in many other languages. You
will be slow, your code might be slow, and everything will look unfriendly.

Obviously some languages are suffering from bad design, but knowing Erlang, I
don't believe it's one of these. Hence my position on blaming lack of
familiarity before syntax or any other reason. You have the right to disagree,
but I would like to know your reasons for it if you do :)

~~~
billmcneale
Sure, here is one example: error messages. I guess even the author of the
article (you?) couldn't come up with a good justification for them. They are
truly horrendous, cryptic and maddening to figure out.

There is just no excuse for a language that's twenty years old to not have
reasonable error messages.

Strings are a whole story of their own, but simply saying "they're not that
important" is just ludicrous if you simply take a look at all the efforts that
every single programming language in existence take to make string
manipulation fast and extensive.

The way the supervisor model is touted as a major improvement is also very
disingenuous: you still need to create and maintain the chain of supervisors
yourself, and nothing stops you from doing that in other languages. Erlang
really has no advantages there.

The syntax and multiple separators also makes it very hard just to move code
around (think: refactoring).

You shrug and say that the beginner just needs to try harder, I'm saying "they
won't, they didn't and probably never will".

Erlang is an interesting academic curiosity but it's too alien and its
creators are too blinded by their own brilliance to even acknowledge these
very simple mistakes, so the world just moved on.

~~~
gordonguthrie
> The way the supervisor model is touted as a major improvement is also very
> disingenuous: you still need to create and maintain the chain of supervisors
> yourself, and nothing stops you from doing that in other languages. Erlang
> really has no advantages there.

This is total nonsense. You cannot write your own supervisors in other
languages. The supervision tree works because Erlang processes can monitor
each other. If you fail, I get sent a message. Error handling or orthogonal to
the calling function stack. This is implemented underneath Erlang inside the
VM and is baked into the entire run-time environment. The following languages
to my professional knowledge do not support that construct: Fortran, Algol,
Pascal, C, C++, VB, VBA, Java, Python, Perl, PHP, Ruby, Lisp and Haskell. All
of these languages handles errors up the call stack.

If you want to write your own supervision trees then you need to implement
your own run-time environment with your own custom language on top of it.

~~~
billmcneale
> This is total nonsense.

Yet, the author of the article himself agrees with me:

"Yes, you need to create and maintain the chain of supervisors yourself."

> You cannot write your own supervisors in other languages.

Now, _that_ is total nonsense. First of all, Turing complete is Turing
complete, so your statement is wrong just on this basis.

Now if you want to argue that it's easier to maintain such a chain of
supervisors in Erlang than, say, in Java, I'll just disagree. You spawn
processes (lightweight processes) all the time in Java and monitoring their
death is a few lines of code.

You just don't need the support of the JVM for that, and going further, I just
don't see what JVM support adds for this particular functionality.

Hence my point that Erlang doesn't buy you much over traditional programming
languages in that area.

~~~
gordonguthrie
Sorry - I call an Emacs skeleton function and use identical supervisors to
every other supervisor. I have never written a line of supervisor code in 8
years of Erlang coding.

The Turing complete argument implies that representation is not important. Joe
Armstrong has a great line for dealing with that red herring. He asks people
to write an algorithm for doing long division with Roman Numerals. Guess what
the representation of a number in Arabic numerals make alogorithms easy even
though Roman Numerals are 'Turing complete'...

Having run an internet bank in J2EE with a budget of over $100m dollars and
then built a clustered full stack in Erlang for under 1% of that I have the
data to prove that your talking mince. Please bring your comparative costs to
the table.

