|
Good OO design makes this relation very explicit in OO languages as well and they are means in the language to achieve it - using interfaces, public/private/protected, annotations like @Override in Java etc. Also, most object oriented APIs provide different means for extending them than subclassing of concrete base classes - that's what interfaces are mostly used for. The argument in the blog post is pretty much worthless as they are not backing it up in any way or explain what they mean with very vague adjectives like "anti-modular". I have been programming functionally in my spare time for the last few years and there is certainly plenty to love about it, but the lack of a clear set of principles and language tools for decomposing systems into manageable modules I would actually view as one of it's main problems at the moment. Decades of writing large-scale OO software, produced a large set of such principles, which applied thoughtfully produce software that really is modular, in the sense that you can keep track in your head of a large program. Things like law of Demeter, substitution principle, open-closed principle and so on and so forth. This imposes a lot more structure upon the code and simply makes it easier to remember things then just using functions grouped into modules/namespaces like it often ends up looking in FP. Now, I'm not saying that there are some inherent problems with modularity in FP - I don't know the full spectrum of functional languages and how they approach this problem of grouping large amounts of code into meaningful pieces. But it doesn't seem that there is some form of a united and well-known approach to this in the functional world, so such claims of "anti-modularity" should be well-backed by arguments and examples of how does FP _help_ modularity. There are surely plenty of people wondering about how to write modular applications in functional languages - just look at the popularity of threads like this: http://stackoverflow.com/questions/3077866/large-scale-desig... Because of the above, I'm really looking forward to the development of languages like Scala, which try to blend the benefits of functional programming like parallelisation friendliness, with the main benefit of object orientation - clear rules for program decomposition. Also, some of the issues are probably orthogonal to what kind of language is used (in certain bounds at least), for example look at this decades old paper: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crite... |