I go on challenging the Erlang-promoted practices. I see that they advise to hide the messaging behind APIWe love messages, but we keep them secret:   Something annoying with the previous example 5> Pid ! {self(), {store, bacon}}.{<0.33.0>,{store,bacon}}6> Pid ! {self(), {take, bacon}}.{<0.33.0>,{take,bacon}}7> Pid ! {self(), {take, turkey}}.{<0.33.0>,{take,turkey}}8> flush().Shell got {<0.51.0>,ok}Shell got {<0.51.0>,{ok,bacon}}Shell got {<0.51.0>,not_found}is that the programmer who's going to use the fridge has to know about the protocol that's been invented for that process. That's a useless burden. A good way to solve this is to abstract messages away with the help of functions dealing with receiving and sending them:12> kitchen:store(Pid, water).ok13> kitchen:take(Pid, water).{ok,water}14> kitchen:take(Pid, juice).not_foundDo my eyes mislead me or it is really easier to learn functional API than the protocol? What if we wrap the API into another API to hide the protocol once more. Will it make situation similarly better?
Hiding the protocol behind API?
api design;erlang