, , , ,

I’m returning to my adventures in Erlang after a couple of weeks’ hiatus and are currently pondering this question…

Erlang (and other languages) makes distributing computation a relatively trivial activity. Given this, should we no longer be as fearful of Martin Fowler’s First Law of Distributed Object Design (http://martinfowler.com/bliki/FirstLaw.html)?

Yes, yes, I know Erlang doesn’t “do” objects but I think the fundamental question remains – should using languages that treat distributed computation as first class citizens reduce the need to be so risk adverse when it comes to using those inherent facilities because of the problems we have traditionally had with badly leaking abstractions around distribution?

In my current toy Erlang application, I could very naturally introduce actors (processes) into my solution and pass messages between them without increasing complexity in terms of size of codebase or IMHO readability.  I believe that with the addition of a small number of extra lines of code, I could do away with a large amount of boilerplate function + guard clause duplication I’ve currently accumulated to simulate the behaviour I would like to achieve using processes and actors – net increase in lines but overall decrease in code.  In fact, in this case, distribution is a more natural concept given the domain is around remote control of vehicles where the controller and the vehicles are naturally distinct computational beings.

Would testing of this code be harder as a result?  In advance of the actual implementation, my instinct tells me that I wouldn’t throw too many tests (i.e., 0) specifically at the distribution mechanisms themselves as I tend to trust the language in that respect.  On the other hand, setup for some of the message passing scenarios worth testing could be trickier.

Doesn’t look like there’s an obvious choice one way or t’other to me – so I’d best get coding and see how things pan out.