Erlang

I think /prague needs a good discussion on Erlang. Discuss!

Because Erlang's expression terminators vary by context, editing code is much harder than conventional languages. Refactoring -- cutting and pasting and moving code around -- is particularly hard to do without creating a bunch of syntax errors.

Consider this code:

blah(true) ->
  foo(),
  bar();
blah(false) ->
  baz().
Lets say I want to reorder the branches:

blah(false) ->
  baz();
blah(true) ->
  foo(),
  bar().
Or change the order which foo() and bar() are called.

blah(true) ->
  bar(),
  foo();
blah(false) ->
  baz().
What's the problem? Note in each example the bar() lines, they have a different character ending each line: bar(); bar(), bar().

You might think if branching as something that no language could ever get wrong. Doesn't seem possible does it? I was young once too. Every time an if executes it should match at least one of the conditional expression branches. When it does not, an exception is thrown.

if
Logging ->
  log("Something happened");
true -> ok
end
The only purpose of the true -> ok line is to give it an else condition to match. That weird taste in the back of your throat? It's probably vomit.

Erlang ifs could be so much more useful if it would just return a sensible default when no conditionals match, like an empty list [] or the undefined atom. But instead it blows up with an exception. If Erlang were a side-effect free functional language, such a restriction would make sense. But it's not side effect free, so instead it's idiotic and painful.


You cannot even call user defined functions in if conditional expressions! For example, this won't even compile because of the call to user defined should_foo(X):

should_foo(X) ->
  X == foo.
 
bar() ->
  if
  should_foo(X) ->  % compile error on this line!
    foo();
  true -> ok
  end.
This limitation is due to Erlang's "when clause" pattern matching engine, which needs certain guarantees from the expressions for static optimization. Erlang allows a subset of the built-in functions (BIFs) in conditional expressions, but no user defined functions can be called whatsoever.



The most obvious problem Erlang has for applications is sucky string handling. In Erlang, there is no string type, strings are just a list of integers, each integer being an encoded character value in the string. It also means you can't distinguish easily at runtime between a string and a list, and especially between a string and a list of integers. Erlang string operations are just not as simple or easy as most languages with integrated string types. I personally wouldn't pick Erlang for most front-end web application work. I'd probably choose PHP or Python, or some other scripting language with integrated string handling.





In C, lets say you have some code:

int f(int x) {
  x = foo(x);
  x = bar(x);
  return baz(x);
}
And you want to add a new step in the function:

int f(int x) {
  x = foo(x);
  x = fab(x);
  x = bar(x);
  return baz(x);
}
Only one line needs editing,

Consider the Erlang equivalent:

f(X) ->
  X1 = foo(X),
  X2 = bar(X1),
  baz(X2).
Now you want to add a new step, which requires editing every variable thereafter:

f(X) ->
  X1 = foo(X),
  X2 = fab(X1),
  X3 = bar(X2),
  baz(X3).

We don't.

A thread containing only “Discuss!” is worthless.