Erlang is Icky

Erlang is giving me a bad taste in my mouth for two reasons.

Before I start whining, let me make it clear that I have only just started using Erlang, and have written a total of 30 lines of Erlang code. This is just my initial impression, and I may change my mind if I ever write larger applications in the language.

The first reason I don't like Erlang is that the syntax is reminiscent of Prolog, but the semantics are lacking everything that made Prolog interesting. Fine, there's no backtracking -- I can live without that. But what I miss most is that Erlang variables are not logic variables. What I mean by this is that you can't pass around unbound variables. The only time you can use an unbound variable is on the left-hand-side of an assignment, where it will be bound immediately thereafter.

This means that Erlang functions cannot be bidirectional, the way Prolog functions can. In Prolog, you can call a function foo(A, B) in such a way that either A or B can be the input variable, and the other can be the output variable. This feature lets you do all kinds of neat things: for example, using the same function for both creating and traversing a tree structure. [Aside: In the Oz language, unbound variables are used to provide an excellent mechanism for synchronizing with worker threads.]

The second reason I don't like Erlang is its anonymous function syntax. I have yet to find a way to write them that doesn't feel exceedingly clunky. For example, here is my first cut at a function to invert an ets table:

% This function takes an ets table SrcIdx, inverts it, and stores  
% the result in the ets table DestIdx.
invert_ets(SrcIdx, DestIdx) ->
        ets:foldl(fun({Key, Vals}, _) ->
                        lists:map(fun(Val) ->
                                        [{Val, Keys}]=ets:lookup(SrcIdx, Val),
                                        ets:insert(DestIdx, {Val, [Key|Keys]})
                                  end,
                                  Vals)
                  end,
                  unused, SrcIdx),
        DestIdx.

This function is way too indented. I would have liked to move the inner fun up a level like this:

invert_ets(SrcIdx, DestIdx) ->
        InsertPair = fun(Key, Val) ->
                             [{Val, Keys}]=ets:lookup(SrcIdx, Val),
                             ets:insert(DestIdx, {Val, [Key|Keys]})
                     end,
        ets:foldl(fun({Key, Vals}, _) ->
                        lists:map(InsertPair(Key), Vals)
                  end,
                  unused, SrcIdx),
        DestIdx.

... but unfortunately this version won't work, because it requires currying, which Erlang doesn't support. The only way for "Key" to be in scope is if the InsertPair fun is nested inside the other fun.

Erlang also loses some points for having exceedingly cryptic error messages. For example, this error message is trying to tell me that the function shell_default:lookup() is not defined:

10> lookup(Q, foo).
** exited: {undef,[{shell_default,lookup,[18,foo]},
                   {shell,local_func,4},
                   {erl_eval,exprs,4},
                   {shell,eval_loop,2}]} **

To be fair though, the error messages aren't really any worse than some of the type-related error messages from hugs (a haskell implementation), and I'm sure I would become well trained at decoding them in time.

One thing I really do like about Erlang is its use of atoms pretty much everywhere. For example, in the error message above, every single word in the error message is an atom, instead of a string. I like how lots of functions return 'ok' as their result, instead of a boolean value. I'm not sure why I like atoms so much -- it's probably just a style thing.

At this point in its development, it's very obvious that Erlang grew organically, in directions that were not envisioned from the beginning. Case in point: the fact that records require header files and a preprocessor.

Posted on May 28, 2003 09:49 PM
More languages articles