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?

  • 2
  • 15
    Buhwaaaah?! OO makes modularity and parallelism easier than in procedural and is not mutually exclusive to FP. Colour me confused.
    – Matt Ellen
    Apr 24, 2011 at 9:00
  • 4
    They have redesigned their curriculum so he has to sell the new program and is making bold claims backed with absolutely no data. There is no evidence that complex functional programs are any more parallel or modular than their OOP counterparts.
    – user7146
    Apr 24, 2011 at 9:59
  • 4
    @Matt Ellen: OOP is decidedly mutually exclusive with FP. FP is predicated on several key concepts of which one is the absence of mutable state. OOP is predicated on the existence of mutable state whose access is controlled by wrapping it in "objects". Mutable state and immutable state are mutually exclusive pretty much by definition. Yes, it's true that you can program in a functional style with many OOP languages, but this is not the same thing as using an FP language. And yes it's true that not all FP languages are pure. This is not saying that FP is compatible with OOP, however. Apr 25, 2011 at 3:04
  • 2
    @JUST: I have a different idea of mutual exclusivity to you. I see pure and impure FP as subsets of FP, and so OOP is not mutually exclusive from FP if you assume that mutability is essential to OOP. Also I don't agree that mutability is essential to OOP. You could achieve and entirely OO system using message passing, and never mutate a thing.
    – Matt Ellen
    Apr 25, 2011 at 7:08

5 Answers 5


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.

  • 10
    The parallelism claims from the functional camp are often overblown. Compilers for functional languages work with a cleaner foundational theory so the implementors have more ways of reorganizing the code before it is turned into machine code but this doesn't mean that if you give OO programmers the proper abstractions for parallelism they won't be able to write clean parallel code. So far procedural programmers have only gotten locks and threads and they have done pretty well I think with those tools.
    – user7146
    Apr 24, 2011 at 10:08
  • 2
    While I generally agree with everything you say here, I'd like to point out that design patterns come in all programming paradigms. For functional programming, I'd point out things such as monads and map/reduce.
    – Anm
    Apr 24, 2011 at 19:15
  • @davidk01 Take Go for example. It supports object oriented programming and has great concurrency primitives. More importantly, it's really taking off for concurrent programming without being purely functional.
    – weberc2
    Dec 11, 2014 at 16:27

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.

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

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

  1. OOP is an approach. In some languages it is implemented using patterns, in others you can directly use built-in language idioms (e.g. Ruby, Objective-C, Smalltalk, Io).
  2. Contrary to common belief, OOP is not about classes. It is about objects and objects are about message passing or an equally non-leaky way of encapsulation and abstraction.

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

  • 1
    +1 for message passing, and +1 for the 'with Java'. Unfortunately if they did remove Java, they'd just replace it with C# and continue its legacy.
    – gbjbaanb
    Apr 24, 2011 at 10:45
  • @back2dos +1 for the critics, -1 for Java. Surely, Smalltalk is "much more OO" than Java, but who uses it? Objective-C is hard for beginners just like C is.
    – maaartinus
    Apr 24, 2011 at 11:04
  • @maaartinus: You will find Squeak to be widely used in the educational and academic area, if that answers your question. Also as for Java: You may like it, I may not. Much like coffee, it's a matter of personal preference and there is no point in discussing that. However Java being unsuitable for an introduction to OOP is IMHO an undeniable implication of Java's nature and the concept of OOP and that is exactly what I said. Java's popularity won't make that go away. As for C, I suggest you read joelonsoftware.com/articles/ThePerilsofJavaSchools.html.
    – back2dos
    Apr 24, 2011 at 11:40
  • @back2dos Squeak may be used in these areas, but at the university I've learned ML. Both are equally unusable in the industry and both are worth learning, because of their concepts. The pointed article is the worst article by Joel I've ever read, it's too long and at the first sight the message seems to be the importance of dealing with segfaults. :D I'd really still suggest Java for teaching OOP.
    – maaartinus
    Apr 24, 2011 at 12:00
  • @maaartinus: What you learned at university matters little in the question what should be taught. You still gave no reasons why one should use Java for teaching OOP, while I gave what I consider quite a solid reason why not to do it. Also you obviously failed to understand the essence of the article: People who cannot cope with problems similarly hard as C shouldn't study CS in the first place. I think CS should not be dumbed down to what every kid that likes computers can understand. If we can't agree on that, then further discussion is a waste of your time and mine.
    – back2dos
    Apr 24, 2011 at 12:21

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.

  • 1
    There already is!
    – quant_dev
    Apr 24, 2011 at 12:43
  • 1
    ++ "You get zealots of every stripe." I was an academic, and my experience was this. Academics love to spout provocative opinions, impressing maybe their students. Apr 24, 2011 at 15:29

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.