I’m not sure I buy this:
When I finally felt that I ‘got’ Erlang, never once did I miss a single OO construct. In fact, I started regarding OO as a burden. In OO languages, every class, every method, every field has so much context around it. To understand where piece of code fits into the big picture, you have to read through the documentation for all the classes and interfaces to which it belongs. Also, OO languages often encourage if not force you to wedge your types into some inhertiance chain in order to reuse code, which results in ugly inhertiance relations that are inflexible at best.
Functional languages like Erlang have the opposite philosophy. They try to minimize the context surrounding a piece of logic— a function. All you have to know is what parameters a function takes and what it returns. There is no implicit link between the function and the data it uses. With single-assignment, you don’t even have to worry about functions mangling the values of your variables. When you’re coding in Erlang as opposed to Java, you think less about the context of your functions and more about what they do and how to compose them together to solve your problem.
Specifically, I’m not sure that “a class which inherits from a class which inherits from a class which inherits from a class…” is necessarily any worse (or any better) than “a function which is called by a function which is called by a function which is called by a function…”
Context is always important. Rooting your development in one high-level abstraction instead of another high-level abstraction probably won’t yield objective gains (though, depending on your mental makeup, it may yield significant subjective gains). The only magic bullet for architectural complexity is architectural simplicity.
Comments for this link are closed. If you'd like to share your thoughts on this link with me, please contact me directly.