[Darmani]

"Object-oriented programming [...] is both anti-modular and anti-parallel by its very nature"

I'm sure this is going to get a lot of discussion, so I'd like to preemptively elaborate on the anti-modular part.

Object inheritance is the moral equivalent of copy & paste.

Suppose you have a class, and you wish to reason about its behavior. You will have to do so knowing that the function definitions therein will be ripped out and replaced with different things. Thinking about the behavior of this will essentially require people writing subclassses to look at the code for the superclass, and vice versa. You've saved the clicking of copy & paste, but not the need to share the code.

There is an exception where inheritance can be well-behaved, and that's where there are a few methods intended to be overridden, with the rest of the class providing meaningful behavior in terms of those few operations. A good example is java.util.AbstractCollection, which provides all sorts of useful operations in terms of the iterator() and size() functions. However, in this case you might as well use an ML module, which makes this relation explicit.

[stiff]

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...