I've been reading a bit lately about functional languages. Coming from 10+ years of OO development, I'm finding it difficult to get my head around how on earth one can point the pure functional approach (i.e. the same method called with the same parameters does the same thing) at a problem where typically (in an OO program) I would need to cache data.
Do we just admit that there might need to be an actor in the program which is not immutable (i.e. the cache). I just watched a presentation by Joe Armstrong on infoq and he seemed pretty dogmatic in this regard!
Do we just admit that looking up data might be expensive (because we can never cache it)? If so, how can we control, for example, the load on some shared resource (e.g. a database)
Is there some magic fairy dust, which I don't know about yet, which solves the whole problem and then makes a nice cup of tea afterwards.
Certainly a google search for "Erlang Cache" seems to return a fair few results...
There is no reason a Cache and a Functional language can't live together. To be functional you just have to obey the constraint that calling the same function with the same arguments you get the same answer.
For instance: get_data(Query, CacheCriteria)
Just because the get_data uses a cache doesn't mean it's not functional. As long as calling get_data with the same Query, and CacheCriteria arguments always returns the same value then the language can be considered functional.
Memoize the function. A cache is just a list/dictionary, and hence can be implemented in a purely functional way.
It is data which must be immutable in Erlang, not actors.
Long-lived actors normally live in a tail-recursive function, the arguments of which serve as their state and certainly can change between calls.
When you call
put_c
, the actor's "state" changes even though all data involved is immutable.