Thursday, October 22, 2009

Armstrong Thesis (Chapter 4)

This chapter takes us in deeper into Erlang programming language and the various techniques of abstracting out concurrency, error handling, and intentional programming.

Armstrong makes an interesting statement by having the expert programmers write the difficult modules and the less experienced programmers write the easy modules. This would be a prime opportunity for applying pair programming in order to take junior developers under your wing and guide them to greatness.

He does go on to discuss how the generic component should hide the details of concurrency and fault-tolerance from the plugins, and the plugins should be written using only sequential code with well-defined types. One of the main points is the plugin can contain errors and not crash the server along with allowing the plugin to be modified dynamically.

I am glad I do not depend on publishing Erlang code in order to put food on the table for myself and the family. The syntax is not terrible or complicated, but it is different from your regular iterative programming language. In the examples I have seen, there are no data types or declaring of variables required. Yes, you can do a lot of exciting things with little code but at what expense.

Armstrong identifies the Erlang philosophy for handling errors:
  • Let some other process do the error recovery.
  • If you can't do what you want to do, die.
  • Let it crash.
  • Do not program defensively.
From the Erlang perspective, exceptions occur when the run-time system does not know what to do and errors occur when the programmer doesn't know what to do. The worker process is introduced as the one doing the real work and the supervisor observes and handles the errors. The idea is to let the worker do what the worker does best and let someone else worry about the errors and how they should be handled. If you think about it, most of the code you write with try-catch blocks have all the functional code and error handling code contained in the same method. The Erlang philosophy is completely different than what you have likely experienced with C++ or Java.


No comments:

Post a Comment