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:
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.
No comments:
Post a Comment