
Erlang encourages poor Functional Design - copx
https://srparish.wordpress.com/2016/10/17/erlang-encourages-poor-functional-design/
======
rvirding
In many cases this article shows a lack of knowledge of how Erlang programs
are written.

~~~
eskil
Robert, I think it's great you comment here now and then. It's awesome to
occasionally get access to the original authors of erlang.

The proposed refactor in the article doesn't look like idiomatic erlang to me.
How would you refactor the code in the article?

I'd do something like this;

    
    
      validate(_DbConn, {error, Reason}) ->
        {error, Reason};
      validate(DbConn, #req{body = ReqJsonStr}) ->
        validate(DbConn, json:decode(ReqJsonStr));
      validate(DbConn, {ok, #login_request{username = Username, password = Password}}) ->
        validate(DbConn, {hash_password(Password), db:find_user(DbConn, Username)});
      validate(_DbConn, {HashedPassword, {ok, #user_details{username = Username, hashed_password = HashedPassword}}}) ->
        % Hashed password matches the found user record hashed password
        % by the power of function pattern matching.
        {ok, "hello " ++ Username};
      validate(_DbConn, {_HashedPassword, _UserLookupResult}) ->
        % Hashed password did not match or user not found.
        {error, "wrong name or password"}.
    

Splitting into exported and "private" functions in module would leave a less
messy api. This simply removes the case usage, coupling, highlights function
pattern matching and makes for easily testable small functions.

