I suppose I should probably stop referring to this series as Trying Out Functional Programming since Erlang is not a pure functional programming language, but rather a declarative concurrent programming language.
The semantics aside, Erlang lets you model a domain as a set of interacting processes. This is a fairly natural - at least for me - way to model most problems. For example, you take the popular board game Settlers of Catan. It is composed of a board with terrain hexes, intersections, and paths. I modeled each hex, intersection, and path as a separate process whose current state drives the determination of rules in a distributed rather than centralized manner.
For example, building a settlement on an intersection is allowed only if no neighbouring intersection has been built on. Instead of checking the neighbouring intersections on each request the neighbouring intersections notify it when they get built upon. As a result the intersection changes it's internal state (the function it is executing) to blocked. As a result it no longer responds to build requests, making it completely impossible to build on it.
Another nicety of the process-oriented or Actor-model approach that Erlang facilitates is the lack of interference from buggy code elsewhere in the system. The intersection in question cannot be coerced into accepting the construction of a settlement. This is due to the fact that the buggy code would have to send a message to change the intersection's state. Thankfully the intersection process is coded to disregard such requests.
This is a very early work in progress and is mostly a mental exercise at the moment, but the possibilities opened up by Erlang's approach are exciting...