[xtho]

"ad 1.)" is completely wrong: From http://www.erlang.org/faq/academic.html:

    10.3  Where does Erlang syntax come from?
    Mostly from prolog. Erlang started life as a modified prolog

Maybe this means Prolog syntax isn't really that weird?

[silentbicycle]

Erlang syntax is derived from Prolog syntax, sure, but with several extra operators and heavy operator overloading. Prolog syntax is cleaner.

The ";" vs "." thing is also on Erlang. Prolog has a function to read the next clause (much like Lisp's read parses the next sexp), and Prolog clauses end in ".". The Erlang interpreter seems to have been implemented so it read every alternative for a pattern in one step, so it ended all except the last with ";". ";" is Prolog's "or" operator, "," is "and". Prolog just ends every pattern with ".".

That said, you get over those minor syntactic issues pretty quickly, and I'll take a language with ugly syntax but beautiful semantics over one with ugly semantics any day.

[moe]

I'll take a language with ugly syntax but beautiful semantics over one with ugly semantics any day.

Sadly the erlang semantics aren't all beautiful either, at least for the things that most people would use it for today.

This quote that I picked up on the erlang mailing list was an eye-opener to me (from memory):

   Erlang wasn't designed to make easy things easy.
   It was designed to make hard things possible.

This explains a lot about the erlang mindset. Things like the obscure syntax or the abhorrent string handling are simply not very high on their priority list.

For example, strings weren't used much in the telecom projects that erlang was original conceived for - hence they didn't get much love until recently.

Similarly the syntax seemed like a good fit for the problems that erlang was looking to solve, because it makes the expression of very complex, concurrent constructs comparably sane.

The problem for us "normals" is that in our codebases we very rarely need that kind of expressive power (and the associated learning curve). We tend to need it in 2-3 critical spots, the remaining 99% is best solved by a general-purpose language that allows for quick iteration.

Introducing the behemoth of erlang to a project only for these 2-3 spots very rarely passes a cost/benefit analysis.

That's why we hack shoddy, slow and fragile bandaids in our go-to languages, instead of using erlang.

[silentbicycle]

The string handling is not great* , but the support for pattern matching on atoms and tuples is nonexistent in most languages, and most programmers don't know to hold that against them.

* Except for the bit syntax, but that's more for binary data.

[chunkbot]

This isn't interesting anymore; Erlang and Prolog simply aren't related beyond the most superficial of syntactical rules. http://stackoverflow.com/questions/3542891/erlang-programmin...