3 ms·
I agree with Dave on the pattern matching in function heads, at least from your description. Garrett Smith’s blog post on tiny functions[0] has heavily influenc
by macintux 5y ago
I agree with Dave on the pattern matching in function heads, at least from your description. Garrett Smith’s blog post on tiny functions[0] has heavily influence my Erlang.
[0]: http://www.gar1t.com/blog/solving-embarrassingly-obvious-problems-in-erlang.html http://www.gar1t.com/blog/solving-embarrassingly-obvious-pro...
- ludamad 5y agoI notice he says the result needs less testing; to me such a rewrite amounts to an audit of the code and thus leaves one with more confidence, definitely. I'd just buy it more perhaps with stringent static types, but I've become a 'gradual typing purist' in a way (in this process, if you're not littering types everywhere you are missing a lot of value)
- nivertech 5y agoThere are lots of contradicting advice in the Erlang/Elixir land. Garret Smith likes microfunctions, while Saša Jurić avoids them. Same with "tagged with statement" pattern - Saša Jurić prefers it over Ecto.Multi in transactions, while this post discourages it's use at all.
- nemetroid 5y agoThe author uses the word "religion" in a jocular manner, which seems appropriate, but probably not in the way he intended. This particular style often seems to get applied as a dogmatic pattern. The underlying principles are good, but the author should have stopped halfway. For example, the article has this: handle_db_create_msg(Msg, State) -> log_operation(db_create, Msg), handle_db_create_result(create_db(create_db_args(Msg)), Msg, State). create_db_args(Msg) -> [create_db_arg(Arg, Msg) || Arg <- [name, user, password, options]]. create_db_arg(name, Msg) -> db_name(Msg); create_db_arg(user, Msg) -> db_user(Msg); create_db_arg(password, Msg) -> db_password(Msg); create_db_arg(options, Msg) -> db_create_options(Msg). create_db(Name, User, Password, Options) -> stax_mysql_controller:create_database(Name, User, Password, Options). There is no shared logic between the different cases in create_db_arg() (creating a false sense of abstraction where there is none). create_db() has to take its arguments as a list* in order for the design to work, but the use of a list suggests homogeneity between the elements, which is not the case. It would have been much better to stop at this point: handle_db_create_msg(Msg, State) -> log_operation(db_create, Msg), Name = db_name(Msg), User = db_user(Msg), Password = db_password(Msg), Options = db_create_options(Msg), Result = stax_mysql_controller:create_database(Name, User, Password, Options), handle_db_create_result(Result, Msg, State). *: which the author also forgot when making the final listing at the end of the blog post.