I have read the controversial article Teaching FP to freshmen posted by Robert Harper who is a professor in CMU. He claimed that CMU would no longer teach object oriented programming in the introductory course sine it is “unsuitable for a modern CS curriculum.”
And he claimed that:
Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature.
Why consider OOP as anti-modular and anti-parallel?
Please consider, that Harper's needs for teaching an introductory CS curriculum class are very different from the needs of a real life project. His job is to teach fundamental concepts (e.g. modularity, parallelism, induction) to freshmen. As such it is very important, that the language (and paradigm) choosen can express these concepts with as little ceremony (syntactical and conceptual) as possible. Familiarity, tool support, available libraries, execution performance etc. are completely irrelevant in this context. So please keep this in mind when considering the following...
The view that OO is anti-modular results from the large number of dependencies to other classes even objects of well designed classes tend to end up with. That this is a problem - even in the eyes of proponents of OO - becomes clear when you look at the proliferation of Dependency Injection frameworks, articles, books and blog posts in the last years (also the rise of mocks and stubs is interesting).
Another hint is the importance of Design Patterns and the complexity of implementing them - as compared to some other programming paradigms - e.g. Factories, Builder, Adapter, Bridge, Decorator, Facade, Command, Iterator, Mediator, Observer, Strategy and Template Method and maybe the Composite are all in some way related to improving the modularity of OO code.
Inheritance is also problematic (e.g. Fragile Base Class Problem) and (subtype) polymorphism seduces one to spilt up the implementation of an algorithm between multiple classes, where changes can ripple through the whole inheritance chain (up and down!).
The charge of being anti-parallel is related to the emphasis of state compared to computation (aka. mutability vs. immutability). The former makes it more involved to express dependencies of subcomputations (which is Harper's take on parallelism!) as you usually can't infer from the location the state is managed (aka. the file, where the instance variable is declared) which outside actors will change it at what point in time.
An emphasis on immutability and computation makes expressing dependencies of subcomputations much easier, as there is no state management, just functions/computations which are combined at the place where you want to express the dependencies of subcomputations.
This is probably a bold claim to make, but I somehow suspect, this Robert Harper never really wrote actual software in his life. All he seems to concern himself with is ML and statical type systems. As big a contribution as that might possibly be, I don't see how his claims about OOP have relevancy.
This article is not controversial. Controversy involves examination, argument and discussion. What you have here is some ignorant academic who puts out two quite fundamental accusations in just one single statement, without bothering to provide any arguments.
The claim about OOP being anti-modular is just utter nonsense. I don't even know how to respond to it, not only no arguments were provided but also OOP by design is an approach to establish modularity with very low coupling between individual modules through means of encapsulation and abstraction.
Claiming OOP is anti-parallel just demonstrates a lack of understanding. OOP doesn't lock in any decisions about concurrency. OOP only dictates to hide them: If properly built, you cannot say, whether an object's implementation is parallel or not.
Thus ultimately OOP and parallel programming are orthogonal. The actor model is an elegant model for concurrency that can be directly reflected in an object system (but needn't be), yielding a formidable combination of both.
The problem with OOP is, few people actually understand it in the sense Alan Kay defined it.
This is why Java is to OOP what pointed sticks are to naval combat. This is also true for many other so called "OOP-languages", but the thing about Java is, that it seems to be a common belief at Universities, that Java should be used to teach OOP.
I agree with all those who think introductions to OOP with Java should be removed from CS curricula. I also think that people who clearly lack fundamental understanding of OOP shouldn't teach it. So it is probably better if Bob sticks to ML for his courses and simply teaches what he has a firm understanding of.
Right now OOP is more of a fashionable etiquette, that people like to stick onto everything. This harms OOP and said people. OOP is not outdated. OOP's golden age is yet to come, when people finally understand what it is about what it is not about (e.g. solving every possible problem by using the keyword class 500 times).
You get zealots of every stripe.
Object oriented programming is not a silver bullet. It never was. What it is, is a victim of hype. Inevitably, people get sick of the hype and a backlash starts to develop (regardless of the actual utility of the paradigm).
Twenty years from now no doubt we'll have some other backlash against functional programming.
I cannot answer this question in full because one can only second guess the vague thoughts of its author. I strongly suspect that this article is about to cause some embarrassment to its author. There is nothing about OOP that would suggest that it is neither modular nor parallel:
Modularity: A major facet of OOP is that it is indeed modular (but modularity means different things in different contexts). So, irrespective of whether the author is talking about generalisation or static programming, he is incorrect.
Parallelisation: As for parallel programming, most frameworks have supported interupts then threading and now proper parallelisation such as what we see in .Net framework 4.0 and the OOP languages that bolt onto it.
I suspect that the author has become a fashion victim in that there is a misconception that functional programming and OOP are mutually exclusive in usage. There are functional styles in OOP languages which are well documented, e.g., Oliver Sturm has published in this area.
The author maintains that OOP is too difficult for freshmen programmers to understand, which may be true - though I doubt it, given the entrance requirements for CMU! The anti-modular and anti-parallel statements may be true in a narrow context when compared to purely functional languages, but are hardly a condemnation of the entire paradigm (which seems to work just fine for those that know how to use it).
The proposed curriculum would teach functional programming in one class, imperative (procedural) programming in another class, and data structures in another class. Once a freshman has mastered these 3 things, he/she should be ready to learn OOP.
Personally I think that's overkill, but academics like to try new and extreme things. As a counterbalance, MIT used to (and might still) teach all of the major programming paradigms in one freshman class.
Oddly enough, both schools have produced some really good programmers. Go figure.
