pgdba.net

I am currently reading this book. Many excellent Java programmers think the tell, don't ask approach is the best way to program. I can see their point, but, having dabbled in functional programming, I am amused at what is considered 'good practice' in different contexts.

In the functional programming world, functions (should) avoid side-effects unless all other options have been exhausted. Thus, it is good practice to combine many 'getter' methods together, operating on lists of lists to derive new values or get something done.

I suppose the key is be consistent: either avoid side-effects, mainly ask and have one function that combines everything together into a process/task (doing something) or follow the 'tell, don't ask' style for separation/decoupling. At the end of the day, it comes down to roles/responsibilities. An object/function/process/piece of code should be expected to either provide information or alter it in any way it sees fit. In fact, good style is probably knowing when to expose data and not. Easily done when each class is tagged as 'read' xor 'write' for a given task.

One way of promoting this is defaulting to immutable, ala Scala (val, collections etc.)

Erlang's influence reigns supreme :-) Looks like I might be able to reuse some erl skills on the JVM.

A supervisor is a regular Actor that is responsible for starting, stopping and monitoring its child Actors. The basic idea of a supervisor is that it should keep its child Actors alive by restarting them when necessary. This makes for a completely different view on how to write fault-tolerant servers. Instead of trying all things possible to prevent an error from happening, this approach embraces failure. It shifts the view to look at errors as something natural and something that will happen and instead of trying to prevent it; embrace it. Just “let it crash” and reset the service to a stable state through restart.

Links:

• http://jonasboner.com/2010/01/04/introducing-akka.html
• http://akkasource.org/