[erlang-questions] Process scope variable
Richard A. O'Keefe
ok@REDACTED
Fri Feb 20 02:06:36 CET 2015
On 20/02/2015, at 3:53 am, Imants Cekusins <imantc@REDACTED> wrote:
> this approach would hopefully run programs very similarly to how
> conventionally written programs would run.
Ah! You mean "badly!"
> I mean, in terms of program
> output, memory consumption, speed.
Explicit state threading makes no difference to
program output and is likely to take LESS memory
than your "state process" approach. If you are
interested in speed, "state process" is going to
take a lot MORE time than threading a record.
>
> I tried writing in the traditional way. It took me too long.
This is a fact about you now and your previous experience.
It is not a fact about Erlang or about pracniques.
I used to see the same thing in Prolog. People would
insist on simulating assignment statements using the
data base, slowing their programs down by huge factors
rather than learn how to do without them.
While at Quintus, I made the mistake of showing one
customer how to make his program simpler and run 700
times faster. We lost that customer!
If you are doing FP right, you won't HAVE a massive state
that needs passing around everywhere. You may well have
a main "server" loop that carries around a fair bit of
state, but that should normally pass off to the handlers
*just* the bits they need, and the revised values,
should there be any, don't get written back to the main
state until the handler is done.
Amongst other things, having state that can be and is
mutated practically anywhere is DEATH to meaningful
exception handling. One of the things about Erlang
that had me nearly weeping for joy when I understood
it is that you aren't faced with the disgusting
nightmare that you are in PL/I, Ada, C++, Java, and
so on: "OK, that didn't work, WHAT HAPPENED TO MY
STATE?" Try reading the Ada design documents at
some point. They are unusually honest. Compiler
optimisations mean that the state that was perceived
by the code that raised an exception probably won't
correspond to the state that is perceived by a handler.
More information about the erlang-questions
mailing list