If you seriously look at the Erlang syntax you will find it is very simple, concise and consistent. We wanted to keep it simple. Yes, it different from most OO languages, most functional languages look different, but that is not surprising as the semantics of Erlang and other functional languages are very different from the semantics of your typical OO and imperative languages like Jave, Ruby and C. If it is doing different things why should it look the same? That would just be confusing.

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.

>> 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?

It was originally in the original Erlang interpreter written in Prolog but you could use it for back-doors in the communication so we removed them. If you sent an unbound variable in a message then the receiving process could reply by binding the variable. We wanted all communication to be explicit.

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.

Because logic programming wasn't the goal of erlang?

The downfall of Prolog's syntax is its weird rules surrounding whitespace and indentation. A few braces and a little more Algol or Lisp wouldn't have killed you, you know.

Of course, Python followed the same strange ideas, so I guess they're well-ingrained now.

I don't know of any rules in Prolog surrounding indentation and the only whitespace rule I know of is that you cannot have whitespace between a functor and the left paren of its arguments. What have I missed?

Armstrong's paper about the history of Erlang is fantastic.

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.

That is a very good paper, well worth reading!

Thanks for the link. Very helpful.

This comment reinforces my perception that erlang is less popular than it should be because engineers are not as strong as they should be.

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.

I have long been fascinated by the principles of business management, specifically those in the well known book "The E-Myth".

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.

Ostensibly, this is what has propped up PHP. Of course calling those who you can convince to absorb a different syntax as "smart" is just a psychological lock-in strategy, rather than an effective sieve.

Not in my experience. I once helped build a team of Elixir developers. There were few people who knew elixir at the time. That simple filter ended up getting us a really great team-- much better than interviewing a bunch of applicants from with other language backgrounds-- the people who wanted to learn elixir, knew it, or were interested in it, were much better than average.

In fact, that's the only effective filter I've found for interviewing.

Our evaluation of "smart" is independent of syntax absorption. It's less that we convince them to absorb a different syntax, more like we select for people who wouldn't get hung up on it.

> They look at the horrible mess of the prolog structures and say "it's not worth it to learn"

Well good, the community is probably better off without that group of people.

What's wrong with prolog syntax?

Different, not same. All computer languages must be Algol.

I thought they all must be java.

We are all JVM now.

> the link seems strangely mistitled

Probably because it was the subject of a pre-existing email thread. We've changed the title to a representative phrase from the text.