Also, the link seems strangely mistitled.
Also, if you again look seriously at the syntax you will see there is actually very little Prolog in it, most of that disappeared along the way when it became functional. What is left are variables, atoms and lists. Records are a bit messy although they are very logical and consistent (again) but no one has come up with an alternative that works. They also fit the language semantics.
Also I personally don't see the problem with learning another syntax. I know and have used about 9-10 so far so what is really the problem?
And I rather like Prolog syntax, it simple, concise, consistent and truly homoiconic though with operators.
I first got interested in Erlang because of its Prolog-like syntax. I was a little bit disappointed when I realised it doesn't actually use unification. That would have been a great feature- why was it left out of the language, I wonder?
I agree though that unification is cool. And I still like Prolog and other logic languages, and have implemented Prolog in Erlang, of course.
We also gave some thought to laziness but felt it just didn't fit as for the type problems in which we were interested. For those problems when things are done is critical, not just that they are eventually done. That would have meant a lot explicit evaluation which defeated the point of laziness.
Of course, Python followed the same strange ideas, so I guess they're well-ingrained now.
It explains how Erlang was developed through a process of trial and error, initially in Prolog and then inheriting a Prolog-like syntax when it became its own thing. Worth reading, lots of trivia about the thought processes behind his and Virding's back-and-forths at the time; and Armstrong is characteristically modest about how they had to invent their way toward a solution, because none existed at the time.
I believe this is the one: http://cobweb.cs.uga.edu/~maria/classes/4500-Spring-2010/pap...
Edit: It also touches on why Erlang's syntax looks the way it does. They initially for a Prologue syntax, and evolved it from there.
The advantages of erlang, over basically every other language, make the "cost" of learning the syntax very low relative to the value of the erlang language.
If you think of yourself as a good engineer, you shouldn't be following the crowd of blubs who use languages simply because they don't tax their brain to learn them.
The idea is that it is easier to grow and scale a business if every role is reduced to something achievable by the lowest common denominator. The book cites McDonalds as an example and how they specify the exact location of pickles on a burger to make sure that a 15 year old can produce burgers indistinguishable from their peers. Sure, plenty of people can cook a better burger than McDonalds, but anyone can cook a McDonalds burger given the equipment and instructions.
In terms of programming, a similar approach may well exist. I've seen it in two forms. First is the enterprise strategy. Standardize on simple, yet inefficient technologies. Anyone with X credential can be as productive as anyone else (this works well because nobody is very productive so its a low bar). This makes hiring and firing much simpler.
The second approach is the "hire smart people and provide them with the tools they need to learn and succeed." I've personally seen great success with "Welcome to the company, let's learn Erlang."
As an engineer who enjoys being challenged I prefer the latter, but I'm not convinced that the first strategy is a bad one from the business's perspective.
In fact, that's the only effective filter I've found for interviewing.
Well good, the community is probably better off without that group of people.
Probably because it was the subject of a pre-existing email thread. We've changed the title to a representative phrase from the text.