He really doesn't care: http://erlang.org/pipermail/erlang-questions/2013-January/07...

  "Today there is an unhealthy concentration on language and 
  efficiency and NOT on how things fit together and 
  protocols - teach protocols and not languages.
  
  And teach ALGORITHMS."

(previous HN https://news.ycombinator.com/item?id=5109052)

I started working with Erlang for work, on and off, for the past year. I had been working with Ruby for a lot longer. I too, liked the Erlang design, but the syntax is a wreck. It's also true, use something long enough and you get used to it. I've noticed long-time Erlang users tend to have this mystical ability to see the underlying elegance expressed by the Erlang syntax while ignoring the syntactic awkwardness.

Elixir brings a lot of good stuff onto the table. I hope the Elixir community incorporates the changes Joe Armstrong suggests.

One in particular: f.() makes perfect sense in the Ruby world because everything is an object (we're sending the '()' message to the 'f' object); but things are built out of functions in the Erlang world, and f() makes more sense there. There are no objects or messages to send them, so 'f.()' gets parsed as an extra dot at the end of the name. I think Armstrong's other suggestions follow in the same vein.

The point isn't to try to make Elixir have a Ruby-like syntax so much as, having distilled the syntax design principles developed in the Ruby community, apply it in Elixir.

"I've noticed long-time Erlang users tend to have this mystical ability to see the underlying elegance expressed by the Erlang syntax while ignoring the syntactic awkwardness."

It's just practice. It no longer trips me up, but I still find it klunky and unpleasant after nigh on 6 years of medium-duty usage.

    lists:map(fun (X) -> X + 1 end, [1, 2])

vs.

    map (+1) [1, 2]

Augh. Yes, I'm cheating perhaps a bit with the (+1), but Erlang syntax has enough other stuff in the way for it to still be fair in the end. For instance, the example Joe gave, where you end up with this long sequence of

    IdentifierA = operationA(ArgA),
    IdentifierB = operationB(IdentifierA, Something),
    ...

"Ant turd tokens", or .,; are a big pain in the neck when refactoring stuff. For instance

    case Something of
       {ok, Val} ->
          do_something();
       _Error ->
          barf()
    end,

The ; and the , are easy to forget about. Indeed, the , might be changed to a . if you eliminate the next expression, and those things can be easy to miss when fiddling with code.

[ fun(N) -> N + 1 end || N <- [1,2] ]

That will produce a list of 2 funs. I think you meant:

    [ N + 1 || N <- [1,2] ].

I picked that as a simple example. Yes, I suppose I should have used a fold, or any of the other "everything else" functions that don't have syntax support. My point still stands.

Comparing Haskell and Erlang syntax isn't even fair. Haskell threw homoiconicity and homogeneity way out the window in exchange for some very nice, mathematical notation.

Erlang is hardly homoiconic, unless you mean Lisp-Flavoured Erlang.

No, it's not. I wasn't being precise. I believe Erlang to have a less complex syntax than Haskell, though, being based on Prolog.

You need to understand that fundamentally Joe Armstrong is 'a good egg'.

No higher praise is there, in my book...