[erlang-questions] erlang sucks

[Anders G S Svensson]

Attila.Rajmund.Nohl@REDACTED writes:
> 
> On Tue, 11 Mar 2008, Ulf Wiger (TN/EAB) wrote:
> 
> > attila.rajmund.nohl@REDACTED skrev:
> >
> > One very good reason for doing this(*) is that Erlang has excellent
> > trace facilities for function calls, but no ability to trace on
> > branching.
> 
> Yes, erlang has excellent trace facilities, it shows me that the 'rfmm'
> function was called - unfortunately it doesn't show that which of the 10
> rfmm functions was called. OK, I could figure out from the argument list
> (also in the trace), but when the argument list is 100 lines long (you
> have to pass the whole damn state as a parameter!), I just don't find it
> that useful. Actually it's faster to insert some io:format calls into
> the code and check the output.

You might not think that when the code is at a customer site and
applying patches isn't something the customer (or the layers of
management between you and the customer) will let you do.

> > I tend to agree that it often leads to less readable
> > code, but I don't agree that it's because of 'if' - at least not
> > in the cases where I've observed it in our code.
> >
> > (*) this = using many small functions - not using illegible function
> >    names, which is just silly.
> 
> I agree that using small functions is a good practice. However, many one
> liner function just makes following the code flow harder, because in the
> end the code is longer. One pattern I often see is:

This is just your opinion of course but consider your example below
and replace handle_error1/handle_error2 with calls to some popular OTP
function say. The advantage of the one-liners is that you can see what
code you've executed by tracing on rc/1 alone. Rewrite it as a case
and you might still be able to if the different branches of your case
return distinct values but if not then you have to trace on these
popular OTP functions as well, which may give you a lot more trace
than you bargained for for starters. Things can get a lot worse in
real code in which constructing appropriate trace to determine what's
going on can be a real chore.

If I had my way I'd remove the case statement along with the if
statement since their overuse can effectively negate the advantage
that the trace facilities provide.

Anders

> 
> some_function(X, Y, Z) ->
>      rc(handle_some_function(X, Y, Z)).
> 
> rc(ok) ->
>      ok;
> 
> rc(error1) ->
>      handle_error1();
> 
> rc(error2) ->
>      handle_error2().
> 
> I think this is just bloat, it's a lot more elegant even in pesudo-C:
> 
> some_function(X, Y, Z) {
>      rc=handle_some_function(X, Y, Z);
>      if (error1==rc) {
>          handle_error1();
>      }
>      else if (error2==rc) {
>          handle_error2();
>      }
> }
> 
> It's shorter by only 2 lines, still, my eyes don't have to jump around
> that much when I follow the code. I guess this could be done in erlang
> with if's, but the crusaders against if's have reached our design rule
> document :-)
>  				Bye,NAR
> -- 
> NOHL Attila Rajmund,  Research Fellow
> Ericsson R&D, Hungary, IP Services      Phone: +36-1-437-7471
> H-1037 Budapest, Laborc u. 1.           Fax:   +36-1-437-7792
> Email: Attila.Rajmund.Nohl@REDACTED