[erlang-questions] Process Dictionary vs Proplist in Web Frameworks

[Attila Rajmund Nohl]

2009/10/29, Geoff Cant <nem@REDACTED>:
>[...] Erlang programmers
> usually only have to think about the function body and arguments to work
> out what its going to do. Sprinkling 'get' and 'put' through the code
> means that an erlang programmer trying to understand your code now has
> to read all the code to figure out why something is happening. The order
> in which functions are called becomes important. The behaviour of
> functions in other modules becomes important because now there's a
> back-channel to propagate bugs, er, state between parts of the code.

This is not related to the process dictionary. If the programmer
implements e.g. a handle_call in gen_server 'A' (or anything that's
called from that handle_call), he has to make sure that he doesn't
call gen_server 'B' if there's a chance that 'B' called 'A' first -
otherwise there would be a deadlock. In this case also a lot of other
code gets important and it's fairly common that a handle_call (or a
function called from handle_call) gets implemented...

Like it or not, it's important that in what circumstances a function
is called - this is a limitation in Erlang's "functional
languageness", but actually this is necessary to do anything useful
with the language.

The process dictionary could be great for environment-like variables,
which are only set once, but used in very many places and it's very
inconvenient to pass around one more parameter. They don't show up in
function traces - but they do show up in the output of
erlang:process_info(), where e.g. the gen_server state is not shown,
even though it would be dead useful.