BT

Object Oriented Programming is out of the CMU Computer Science Introductory Curriculum

by Jean-Jacques Dubray on Mar 20, 2011 |

Robert Harper and Dan Licata, Professors of Computer Science at Carnegie Mellon University, announced last week that they have decided to "eliminate entirely" OOP from the CS introductory curriculum.

it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic.

Prof. Harper and Licata will be teaching a new course on functional programming to first-year prospective Computer Science majors. The curriculum also includes:

a new course on imperative programming created by Frank Pfenning, and a planned new course on data structures and algorithms, which will be introduced by Guy Blelloch this fall.

Philip Schwarz commented:

Why do you say that OO is anti-modular?

In Object Oriented Software Construction, Bertrand Meyer showed that OO decomposition meets all of the following:
5 criteria:
Modular Decomposability
Modular Composability
Modular Continuity
Modular Protection
Modular Understandability

5 rules:
Direct Mapping
Few Interfaces
Explicit Interfaces
Information Hiding
Small Interfaces (weak coupling)

5 principles:
Linguistic Modular Units principle
Self-Documentation principle
Uniform Access principle
Open-Closed principle
Single Choice principle

In a world that is increasingly "actionable" as opposed to "executable" because every system today is a distributed system, in an era where software architecture has not yet emerged at the programming model level despite attempts like Enterprise Java or Spring, is it really reasonable to step back to train new generations of future Software Engineers just on the basis of the merit of functional programming? Is it really important to focus on "programming" when software engineering is mostly a "system engineering" activity.

It might, at a very minimum, be important for this new generation to include in the CS curriculum what what Barbara Liskov, winner of the 2010 Turing award, had to say about Functional Programming.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

This is how CS should be taught by Dean Wampler

If you've read "Structure and Interpretation of Computer Programs", by Abelson and Sussman, you'll appreciate that this is really the best way to learn the fundamentals of computing, whether or not you believe in OOP. Note that OOP will still be an optional course in the curriculum.

Concerning the "anti-modular" claim about OOP, a related post, What Is a Functional Language, briefly claims that OOP is anti-modular because of inheritance and the tendency for class-based organization to spread behavior around programs, as well committing the other "sins" of imperative programming.

The post doesn't say why inheritance breaks modularity, but I'll guess they are referring to the problem that subclass overrides can easily violate Liskov Substitutability. Meyer's Design by Contract was designed in part to prevent this, but even in Eiffel it is up to the programmer to define such contracts.

One of the perceived benefits of class-based organization is that each class decides for itself what a particular behavior (i.e., method) should be. This does in fact tend to "spread behavior around", as it is common for class hierarchies to be scattered over a code base (including 3rd-party libraries). I've come to believe that Haskell-style "type classes" are better at localizing (most) behaviors and objects should be relatively "anemic" (to use the Domain-Driven Design term). This approach is especially useful for so-called algebraic data types.

We've realized for a while that class hierarchies are a form of strong coupling. Strong coupling limits reuse, evolution, unit testing, etc. So, we now prefer composition over inheritance. Taken to its logical limit, you arrive at functional data structures, like immutable lists, maps, etc. and uniform operations like fold, map, etc. These turn out to be far more reusable and composable than ad-hoc objects. When was the last time it was easy to integrate your object-oriented library with someone else's?

Re: This is how CS should be taught by Dan Tines

It's interesting that Rich Hickey consciously developed Clojure as an anti-OO language, but the end result is a language that is better at what the whole purpose of OO in languages is (e.g. the expression problem, dispatching mechanisms).

I've always had a problem with class-based OO, and also believe that data and behavior are really orthogonal issues not to be conflated, and there is a strong case for many objects to be anemic. I guess the problem I have is what does belong in a class. It's a hard problem that many developers think they've solved in their own designs, but probably haven't. Most designs are just ad-hoc, and could have been a gazillion different ways. I don't believe there's as much room for massively different designs when you have simple data structures and functions operating over them.

intellectual cleansing by Gerald Loeffler

i don't believe that this decision is doing a great service to the students, and i'm deeply skeptical about declarations of "truth" and "the one right way":

To eliminate OOP from the mandatory study path would allow CS students to graduate without serious exposure to the one dominant programming paradigm of the present and foreseeable future.

To discuss and improve on the (well-known!) shortcomings of OOP in an enlightened way requires computer scientists to fully understand OOP - not to be shielded from it as if it were a heretic strand of religion.

cheers
gerald

Re: intellectual cleansing by Werner Schuster

@Gerald: You apparently missed this part of the quote:
"A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic."

Re: This is how CS should be taught by Antonio Mota

The fact that (too many) people use OO languages - well, I'm referring mostly to Java - use it in a imperative or procedural way doesn't mean it's principles are not correct. The fact that people use Java in a anti-modular way doesn't turn Java in a anti-modular OO language - you can't blame the tool for doing a bad job if you're not using it correctly.

On another point, you refer to the Liskov Substitutability principle here, and I confess I'm a little ambivalent here - should that principle be considered a OO fundament, or should it be a little like a "nice-to-have"? Isn't this principle opposed to expandability (and to a certain extent to extensibility)?

Re: intellectual cleansing by Gerald Loeffler

You apparently missed this part of the quote:
"A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic."


no, i didn't miss it, but firstly OOD is not OOP and secondly from "who wish to" i've deduced that this is an optional course: as mentioned before i don't think that in 2011 a balanced CS curriculum is complete without OOP, and one eliminates it at the expense of the well-roundedness of the students' education.

huh? by Andrew McVeigh

from the CMU description:

"Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum."

This seems polemical and ideologically driven. "By its very nature"? What characteristics of OO contradict essential modularity principles? I'd be very interested to see the rationale for this statement.

I personally don't believe that OO is antithetical to modularity at all - I lecture on advanced OO techniques and hierarchical component structures, and modularity covers a large part of the course. Sure, objects are a secondary construct that can be built up from closures, but modularity and objects tend to be different axes of a design, rather than mutually exclusive. Modular structures also formed the bedrock of my original phd research, which is within an OO context...

Re: This is how CS should be taught by Dean Wampler

My view is that you compromise object composability if you sacrifice Liskov Substitutability. Of course, most class libraries in most OO languages break this rule sometimes (and Eiffel, oddly enough, even explicitly embraces this as a feature). Not every class supports comparison, valid equality tests, etc. java.util.Collection declares methods that may throw UnsupportedOperationExceptions in implementing classes. This problem is usually ignored by people (and I got flamed once for mentioning Ruby examples ;), but it effectively means that you have to know whether or not you can plug a particular object into an abstract dependency that the object supposedly supports!

Like all design choices, it's a tradeoff.

Re: intellectual cleansing by Jean-Jacques Dubray

Werner.

I think Gerald is correc. Students from CMU will be able to graduate with a CS degree without ever touching OOP. OOP is now optional.

On another note, it looks like there is no Model Driven Engineer class either.

Re: huh? by Dean Wampler

Here's the issue for me; having done OO programming for 20 years, I agree with you that there are some powerful and elegant OO composition and modularity techniques, but I've come to realize that, in practice, objects aren't yielding the succinct, reusable, and adaptable code that we expected. In part, the problem is the level of abstraction is wrong. That may sound crazy, but if you look at all the successful modular systems in the physical and software world, you notice that they are based on simple, even simplistic, low level "data" structures and protocols for use. Examples include roads, plumbing, electrical networks, digital circuitry, and HTTP. All have very basic, but well-defined "plug-in" interfaces and protocols for use. On top of those structures are built high-order structures, protocols and behaviors.

Functional Programming fits this model very well. There are core data structures, like immutable lists, maps, etc., and core protocols like fold, map, filter, and pattern matching. These constructs promote rich composability, reuse, and robustness.

The paradox of objects is that the freedom to build rich abstractions undermines the essential characteristics of modularity. Your "Customer" class rarely fits into my "Payroll" system without writing bridge code, etc. Nor is it likely that your Customer class naturally supports fold, map, pattern matching, etc. without effort on your part. That's why I seldom declare class hierarchies for my domain model. Rather, I try to define only the fundamental types with well defined "algebraic" properties so they work well with the functional abstractions I just mentioned. In my Payroll app, I'll define a type for Money, which is well-behaved and stable, but not Customer, which is too fluid and amorphous; I'll use a map for those "objects". I still use some inheritance when working in languages like Scala, but mostly for "infrastructure", meaning types less directly connected to the problem domain, like collections and other abstract data types.

Re: intellectual cleansing by Werner Schuster

... and _offering_ an optional course means that CMU is committing "intellectual cleansing"?
It ain't, unless CMU students are routinely tied to a post and whipped until they swear to renounce all OOP and it's evil minions.

If students can't be trusted to pick up a book on their own or use any of the mainstream languages, all of which nowadays employ some form of OOP, then they have bigger problems anyway.

OOPSLA and JAOO are now SPLASH and GOTO, resp. by Faisal Waris

Note that OOPSLA and JAOO have been renamed to SPLASH and GOTO, respectively.

My local university where I am pursing post-graducate studies has dropped Java in favor of Python.

Not sure why but my guess is that Java is not a functional language whereas Python is both functional and OO.

The writing is on the wall. It's time enterprises took note and start to allow functional languages into the the mix.

Re: intellectual cleansing by Jean-Jacques Dubray

Werner:

I think we should focus on the debate:
a) is it justified to remove OO from mandatory classes to graduate (this is a clear message from the faculty that OO is no longer considered essential to succeed in one's career, can you grow as a software engineer without OO knowledge?)
b) is it in line with what the industry need? i.e. will companies hire people that don't know anything about OOP?
c) has OO failed to deliver what the industry thought it would?

Whether someone does something on his own is irrelevant. What is important is the direction of our industry moving forward.

Re: huh? by Andrew McVeigh

> The paradox of objects is that the freedom to build rich abstractions
> undermines the essential characteristics of modularity. Your "Customer"
> class rarely fits into my "Payroll" system without writing bridge code...

I agree there's essentially a conflict between strong encapsulation and reuse in classical OO. Is this your point also?

I just don't see this as being an inherent limitation of the OO paradigm, though. I see it as a limitation of OO as often taught/applied.

> ... if you look at all the successful modular systems in the physical and software world

Yes. Many successful systems are built on a foundation of simple data protocols. Not all though. Interestingly, many OO systems I have worked on trended towards a thin substrate of data communications, with an additional layer of rich objects sitting above this.

> Examples include roads, plumbing, electrical networks, digital circuitry

Actually, I would cite the circuit board/chip paradigm of electronics as a good example where modularity, encapsulation and reuse do not necessarily conflict. Applying these techniques to software (building on the OO paradigm of classes/interfaces) yields similarly +ve results: this missing parts from classical OO are the introduction of an evolution operator and modules. For (self supporting ;-) evidence I cite my own work on extensible systems: www.intrinsarc.com/research
I'd also claim that aspect oriented programming is a limited form of this, where evolution is weak...

So, I'd simply argue that junking OO because of the apparent conflict between encapsulation and reuse is to discard a valuable paradigm for reasons not intrinsic to that approach.

Re: huh? by Dean Wampler

I'll have a look at your work. I love the thrill of learning something new, even if it means being proven wrong ;)

Of course, there have been successful object-oriented systems that live up to the promise, but I think our fundamental mistake, in retrospect, was not basing OOP on rigorous functional roots. That would yield better results, IMO.

Aspect-oriented programming is an interesting case. I was an active participant in that community for a long time, but I'm now skeptical of its value. It really is a modularity nightmare because it completely breaks the ability to reason about a module's behavior in isolation; you have to know the global context. Many in the community have studied this issue, of course. This is unfortunate since AOP is designed to restore modularity!

I also think that a lot of the cross-cutting concerns collapse to localized concerns when you eliminate object middleware. In other words, cross-cutting concerns exist primarily because class-based systems spread the functionality around the code base (as was claimed in the blog posts we're discussing!). You can address these concerns more easily and locally at lower points in the layers of abstraction. A great example is the use of Monads to wrap IO and other "impure" actions.

Re: intellectual cleansing by Dan Tines

Werner:

I think we should focus on the debate:
a) is it justified to remove OO from mandatory classes to graduate (this is a clear message from the faculty that OO is no longer considered essential to succeed in one's career, can you grow as a software engineer without OO knowledge?)
b) is it in line with what the industry need? i.e. will companies hire people that don't know anything about OOP?


Regarding (a) and (b). There's a good chance that those faculty members would tell you that CMU isn't a vocational school.

Seems ok to me by Brian Edwards

My intro to computer science (I'll say 3 semesters worth) included some MS Excel worksheet boolean algebra to break the ice, C, x86 asm, and finally Haskell. The more advanced courses then either used C++, Java, or Lisp. I also took an optional course on C++. I enjoyed working with all of them but there were a few weeks during each of the courses where I proclaimed "who the hell uses this language." It made me feel very stupid at times, especially lisp/haskell. In retrospect they all were worthwhile for learning (yes, even calling the built-in functions in Excel.).

As that CMU blog says this applies to the intro courses. I believe the same thing was done in the past as universities transitioned from punch cards, to asm, to C, to Java, then I guess now Python. So they've flipped from FP to OOP a few times already. They are just keeping up with the times. Incoming freshmen most likely already use Python or Ruby but I'm assuming in an OOP sense. I would consider this announcement worthy of so many comments if CMU completely removed all OOP from their curriculum.

Re: intellectual cleansing by Jean-Jacques Dubray

though I agree, OOP seems to be broad enough and widespread enough to be considered going beyond the vocational question. OOP seem to have grown as a foundation of our industry (we can debate right or wrong), could an engineer really function (no pun intended) without some solid knowledge of OO?

Re: huh? by Andrew McVeigh

> ...but I think our fundamental mistake, in retrospect, was not
> basing OOP on rigorous functional roots

(please bear in mind that I'm not qualified to critique the functional approach particularly, despite sharing an office with haskell programmers for the last 5 years... it doesn't really "chime" with me)

I don't really understand how the 2 paradigms can be completely reconciled at their core. If the starting point of objects is that they encapsulate mutable state and operations on that state, and the starting point of functions is mathematical composition over immutable data, what is the common viewpoint? The closest I've personally seen is the Oz multi-paradigm work but that has mutable state also IIRC.

> Aspect-oriented programming is an interesting case...
> but I'm now skeptical of its value

I agree; IMHO it's too weak. This is my understanding: aspects can compose, but can't explicitly interact, despite causing unintentional interaction due to side effects. Aspects have limited ability to change underlying behaviour, and also lead to a secondary/less powerful development axis. As a result they seem to primarily be used for technical functions such as transactions, logging etc, which are completely orthogonal to any business logic...

The approach of my work on Evolve is 3-fold:

1. constrain OO back to an original compositional component model
(exactly like electronic circuits)
2. introduce modules to group collections of components
3. introduce the resemblance and evolution operators to allow a module to evolve any modules it depends upon

The operators in (3) allow compositional structures to be modified in a way which avoids having to recreate them when an abstraction at the base of the compositional tree needs to be changed. In my industrial work (inv banking etc, 20+ yrs) this is the most common scenario where reuse breaks down.

A 5 min intro video is here: www.intrinsarc.com/movies/evolve.html
I'm presenting it at ICSE in May this year.

I think these concepts are possibly applicable to functional systems also - in those systems, don't you get complex compositions of functions, where reuse mandates a change in a function at the bottom of the tree also?

Re: huh? by Faisal Waris

Solutions to the expression problem in various languages highlight Haskell as being the most flexible. The key is type classes in Haskell.

Here is a detailed lecture (rather long):
channel9.msdn.com/Shows/Going+Deep/C9-Lectures-...

A sufficiently rich type system may be the key to evolvability - rather than being OO or functional.

I think the anti-OOP movement is getting out of hand by jean-simon Larochelle

Yes. it is true that OOP has its share of imperfections, traps and pitfalls. This to me is not a valid argument to start learning about it later but the opposite: start learning about OOP early so that you can get really good at it. Forget about multithreading for a moment and consider that most students comming out of university I have encountered could not even create a well designed @NotThreadSafe class. The real world is full of OO languages and tools that will not disappear overnight and we need programmers to develop and maintain the existing code base.

May be more correct to look at objects as duals of ADTs by Sukant Hajra

I think it's important to start with the arguments made in Cook's On Understanding Data Abstractions, Revisited paper.

A lot of people can't really describe the difference between ADTs and objects very well. What I love about Cook's paper is that it's a pretty readable and objective comparison. Also, he's deliberate to exclude inheritance, mutability, and industrial implementation headaches from the base abstraction of objects. Both ADTs and objects suffer from what Philip Wadler coined "the expression problem," but in orthogonal ways. For objects, it's easier to make more abstractions (objects) implement an interface, but it's tedious to add more methods (change the interface). For ADTs, it's easy to add new methods, but tedious to change the abstraction.

But a lot of people are unfairly comparing ADTs augmented with dispatching mechanisms like type classes to objects. I believe that mixins (like Scala's traits) are the "object-oriented" way of dealing with the expression problem. So if we're going to compare ADTs with type classes to objects, it's really only fair to augment objects with something like mixins.

But Cook points out that objects do something that ADTs just don't -- encapsulation. But he also makes the passing remark that perhaps encapsulation is overrated.

So this paper really impacted me quite a bit with respect to looking at the comparison of objects to ADTs as somewhat of a wash. What's interesting about Scala is that you can hybridize OO and ADT approaches, embedding one inside the other. Case classes can implement an interface and encapulate data. And normal classes can use ADTs internally.

It seems a lot of people are engaging in strong extremism. Also, I think Harper at CMU has a delightfully subversive tone that some people are falling prey to. Just look at his blog. He's got a whole post ribbing the "dynamic language" movement. The content of the post wasn't really all the controversial, but it's got a strong tone.

Still, though, he's taken strong steps to defer object-orientation to later in a student's education. Personally, this feels fine to me. Starting with the power of first-class functions is pretty damn vital. I loath to use an object/class-oriented language without well-implemented first-class functions with closures. But first-class functions with closures can go pretty far without objects or classes.

Re: May be more correct to look at objects as duals of ADTs by Andrew McVeigh

> I think it's important to start with the arguments made in Cook's
> On Understanding Data Abstractions, Revisited paper.

thanks for the reference, i'll check it out.

> But he also makes the passing remark that perhaps encapsulation
> is overrated.

I think this accords with many people's experience - something has to give in advanced OO usage and it is often this. However, the poisonous combination IMHO is loss of encapsulation coupled with mutable state, particularly on a system maintained by people with varying degrees of technical maturity.

> Also, I think Harper at CMU has a delightfully subversive tone
> that some people are falling prey to.

I think being subversive and polemical is fun, but is it fair to expose students directly/only to this without presenting the facts of several paradigms and letting the students work it out for themselves? Let's face it, this is CMU, not some vocational college.

One of the really admirable things about SICP was that the authors perhaps felt the same way, but took the time to present the tools to understand the building blocks and the limitations of class-based OO. By giving the basics of closures and fcfn's, they gave students the freedom to understand and critique.

Re: I think the anti-OOP movement is getting out of hand by Andrew McVeigh

> This to me is not a valid argument to start learning about it later
> but the opposite: start learning about OOP early so that you can
> get really good at it.

i feel the same way, with a caveat. i think the way that OO is taught can either embed the limitations of the paradigm, or free students to understand and critique the approach.

Re: intellectual cleansing by Faisal Waris

Not opposed to OOP and I think it is essential for today's world.

However, I believe that functional concepts should be taught first while the mind is still malleable. Learning functional thinking becomes much harder after the mind has been conditioned with imperative programming.

In my opinion OOP is easier to pick up and should be done later.

There are many hybrid languages today that can serve this dual purpose - Scala, F#, OCaml, Python, Clojure, etc.

Great ! by Leandro Moraes

Good luck to the students trying to get a job while functional programing is not mainstream ...

discussion of this post over at the "Java Posse" Google Group by Philip Schwarz

Object Thinking by Philip Schwarz

Some excerpts from David West's excellent book, "Object Thinking":

Object-oriented ideas and principles are poorly understood
...Why does Alan Kay say the object revolution has yet to occur?
...[because] software developers tend to be so focused on what and how that they forget to explore questions of why.
...Thirty plus years have passed since Alan Kay coined the term object-oriented...The ubiquity of object terminology does not mean, however, that everyone has mastered object thinking. Nor does the popularity of Java. Nor does the de facto standardization of object modeling embodied in UML.
...An argument can be made that the contemporary mainstream understanding of objects is but a pale shadow of the original idea. Further, it can be argued that the mainstream understanding of objects is, in practice, antithetical to the original intent.
...Thinking like a computer is the prevailing mental habit of traditional developers...begin by thinking what a computer has to do first and write that down; then think about what the computer has to do next, and continue that way until you have described the last thing the computer must do (David Parnas)...Object thinking focuses our attention on the problem space rather than the solution space. Object thinkers take the advice of Plato, Parnas, Fred Brooks Christopher Alexander, and many others by letting the problem define its own solution...they are not thinking about the structure of a computer program; they are talking about finding the naturally occurring divisions and classifications ("natural joints") in the problem space. This is essential because the naturally occurring modules in a problem space are not isomorphic (exhibiting fitness between context and solution) with the modules discovered and defined when you are thinking about the design of a computer program. But they can be. Thinking like an object will lead to a greater degree of isomorphism between objects found in the problem space (the enterprise domain) and those in the solution space (the computer program) than thinking like a computer. Isomorphism of the modules (objects) in problem and solution space is a desirable, in fact essential, quality for software...the leading advocates of "behavioural objects", Kent Beck and Ward Cunningham invented the CRC card approach to finding and defining objects, the most popular of the "behavioural methods"
...Plato suggests three things: decomposition is hard (and anyone really good at it deserves adoration), any decomposition that does not lead to the discovery of things that can be recombined—composed—is counterproductive, and the separation of one thing into two should occur at “natural joints.” By implication, if you decompose along natural joints—and only if you do so—you end up with objects that can be recombined into other structures. Also by implication, the natural joints occur in the domain, and “bad carving” results if you attempt to use the wrong “knife”—the wrong decomposition criterion...Decomposition is accomplished by applying abstraction—the “knife” used to carve our domain into discrete objects...Traditional computer scientists and software engineers have used data (attributes) or functions (algorithms) to decompose complex domains into modules that could be combined to create software applications. This parallels Edsger Wybe Dijkstra’s notion that “a computer program equals data structures plus algorithms.”
...The fact that a computer program consists of data and functions does not mean that the nonsoftware world is so composed. Using either data or function as our abstraction knife is exactly the imposition of artificial criteria on the real world—with the predictable result of “bad carving.” The use of neither data nor function as your decomposition abstraction leads to the discovery of natural joints. David Parnas pointed this out in his famous paper “On Decomposition” (www.cs.umd.edu/class/spring2003/cmsc838p/Design...). Parnas, like Plato, suggests that you should decompose a complex thing along naturally occurring lines, what Parnas calls “design decisions.”
...Both data and function are poor choices for being a decomposition tool.Parnas’s predictions have consistently been demonstrated as the industry blithely ignored his advice and used functional decomposition as the primary tool in program and system design for 30 years (40 if you recognize that most object development also uses functionality as an implicit decomposition criterion). Using data as the decomposition abstraction leads to a different set of problems. Primary among these is complexity arising from the explosion in total data entities required to model a given domain and the immense costs incurred when the data model requires modification.
What criterion should be used instead of data or functions? Behavior!
...Behavior is the key to finding the natural joints in the real world. This means, fortunately, that most of our work has already been done for us. Software developers simply must listen to domain experts. If the domain expert has at hand a name (noun) for something, there is a good chance that that something is a viable, naturally carved, object.
...Only when we are confident that our understanding of the domain and of its decomposition into objects mirrors that of the user and the natural structure of that domain should we begin to worry about how we are going to employ that understanding to create software artifacts.
... If we “think in Java,” don’t we “think like objects” instead of engaging in the kind of “computerthink” discussed by Parnas? Unfortunately, no...Although you can implement object thinking in any programming language, knowing an “OO” language is not sufficient to engender object thinking...Languages such as Java and object-modeling tools such as UML effectively define an object as the encapsulation of data structures and algorithms. According to this kind of definition, an object is nothing more than a very tiny COBOL program... A COBOL program is the encapsulation of data structures (data division) and algorithms that operate on those data structures (procedure division)...developers tend to perpetuate old thinking habits, albeit sometimes to a lesser degree.
...It’s useful to generalize Parnas’s observation to accommodate datacentric development and development in nonprocedural languages such as Prolog and Lisp. The essence of thinking like a computer is thinking in terms of the means of problem solution. You view every development problem through the lens of the means you intend to use to solve that problem. In datacentric development, the means of solution consists of relations and relationships; for Prolog and LISP, a set of propositions or state declarations.
...The generalization being made here is a variant of the adage, “If your only tool is a hammer, every problem looks like a nail.” Following Parnas, I’m suggesting that software development has been distorted and that all the problems noted by Parnas persist because “our only tool is a computer, so every problem looks like a virtual machine.”...

Please help: I do not understand by Erik Schipper

"it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic."
I really do not understand anything of this. Perhaps someone can help me and answer my questions?
- What are the real-life prolems caused by this anti-modular nature of OOP?
- In what way is this new method different?
- Why do you think this different way will prevent these problems of OOP?

Hope you can help me with this. I am always interested in new methodes, but I need to understand.

Thanks!

Thanks a

Re: Please help: I do not understand by Andrew McVeigh

> "it (OO) is both anti-modular and anti-parallel by its very nature"
> - What are the real-life prolems caused by this anti-modular nature of OOP?

The quote is from the 1st year CMU lecture outline on FP (15-150). I believe the 1st year course comprises 15-110 (introduction), 15-221 (imperative computation) and 15-150 (functional computation). I could be wrong. The 15-110 course is changing to use Python, which is generally programmed in a (stateful) class-based OO manner.

So, as the quote is from FP practitioners, it's perhaps not surprising they say this about OO. The dean's perspective report (reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS...) gives a bit more nuance, but only contains a passing reference:

"Some common forms of modularity in computer science include procedures, data abstraction, and object-oriented programming. Of course, modular design is also used in many other domains, ranging from building construction to product supply chains, but the use of modularity in computer science can be much more complete and pervasive."

It's hard to criticise this, as it is stating the obvious and seems much less argumentative than the 15-150 statement about OO. The dean's report is well written and more or less what you'd hope from a fwd thinking school like CMU - it is trying to teach students to think about programming.

At a guess, I'd expect that the criticisms are referring to the fact that strong encapsulation in classical OO tends to make it difficult to incorporate new concerns into a system and to reliably parallelise algorithms based on mutable state. Of course, an OO advocate might make related but different criticisms of FP ;-P

Re: Please help: I do not understand by Sukant Hajra

I don't want to say too much about the anti-modular statement. Cook's paper and some of my comments above address that enough to get the conversation started. I'm pretty sure both objects and ADTs are "anti-modular," and require the augmentation of mechanisms like mixins and type classes to regain their modularity (address the Wadler's Expression Problem).

But I do want to comment on the anti-parallel claim. I'm pretty sure this is a lobby for immutability, and ideally referential transparency. Harper has a blog post that's a little long-winded, but addresses his perspective on this point directly enough.

I know people that are attracted to Haskell with hopes that it would "automatically parallelize/distribute" but the state of the art isn't there yet last I checked. We're still left with manual partitioning of our algorithms. The mutable state guys have gotten good at that with practice, but at the heart of many of their successes are lessons borrowed from functional programming. Immutability to reduce synchronization is one example. But a more blaring example is Map-Reduce, which has obvious strong connections to FP.

But here's my complaint about CMU's off-hand remarks. They are assuming a lot about object-orientation, and they would be correct only if looking at industry as the reference implementation of OO, with no theoretical underpinning. This is why I like Cook's work. He's lobbying for the academics to think more broadly about the theory of objects, and separate from all the chaos industry has created around the subject.

Ultimately, I look at Harper's remarks as inflammatory. They only make sense in the context of certain assumptions that aren't universal. It's got this "academia versus industry" mentality. There's a tradition of this. Dijkstra's writings can be similarly seething. And last year I saw a lecture by Tony Hoare in which he spent an obscene amount of time on seven axes of differentiation between "the engineer" and "the scientist." He made claims that they should work together in the end, but he didn't really get to that point. It was a blaring hole in the structure of his presentation -- good rhetoric, awful composition. All he ended doing was rallying a crowd of computer scientists to believe they were on the right side of the problem, and those profit-driven, short-sighted, productivity-driven, resource-constrained, (there were other axes I can't remember) sad engineers were just stuck in the anti-academic mire of pragmatism.

I don't mind the differentiation, but the tone is churlish, and we should hold academics to a higher standard. I get particularly incensed by Hoare and Dijkstra because they're legends, and this exchange of complete arguments for impassioned rhetoric just slows down progress -- both academic and industrial. If Harper ever obtains that legend status, I'd make pleas for him to make his arguments without the inflammatory side comments. Actually, for practice, he should just start now.

Re: Please help: I do not understand by Jean-Jacques Dubray

I believe the lack of modularity of OO was true but has been addressed at least by 3 major architectural frameworks: Spring, SCA and OSGi, with different degree and area of success.

The modularity problem stems from the a) unidirectionality of Class interfaces and b) the strong coupling between class and instantiation (via constructors).

Unidirectionality of interfaces forces all interactions to be client/server type as opposed to peer-to-peer. This is unrealistic. Software "layers" are totally unrealistic as a modular mechanism. This has nothing to do with OO.

In most scenario, interactions between classes are peer-to-peer: A calls B, B calls A. This is how the world works, trying to represent real world concept with unidirectional interactions is the most stupid idea that ever landed in the software industry.

In OO, the fact that the class is responsible for instantiating instances doesn't help. If Class B needs to invoke methods on an object of Class A, it basically has to know a lot about it (an interface at a minimum).

Now, it is easy to fix that and it has been: Spring, SCA and OSGi all offer "assembly" mechanism based on the concept of bidirectional interfaces and a clear view of the interactions rather than the classes themselves. The runtime is capable of "assembling" objects without them knowing much about each other other than they participate in the same assembly.

It seems to be that our industry, be it for REST, functional, ... is all looking to ignore the obvious: computers are here to manage state, computation is a negligeable activity compared to the amount of state computers manage, yet all programming models are geared towards computation, rather than state management. As a result, software engineering never passed the "function" concept: A calls B is the basic building block of computation, unfortunately, it is not very helpful for state management. Hence all these erroneous statements about the suitability of X, Y or Z, and our industry constantly circling back to its origins: Turing based computation. If Turing had been an information modeler, our programming languages would look very very different.

don't be obtuse by Luis Espinal

Good luck to the students trying to get a job while functional programing is not mainstream ...


Google, MS and Amazon would beg to differ... and so many other small and large players in the market.

You are being deliberately obtuse here. For starters, there are jobs out there that do require applicants to know functional programming. Don't believe me? Just fire up a dice search on Java (or C#), and you'll see the increasing trend demanding Java/C# programmers to be exposed to functional programming.

Secondly, FP is already mainstream in C# with the support for closures and LINQ. Lambdas are about to be added to C++, and they'll make it into Java 8. Enterprises devoted to Java are waiting in hot chairs for lambdas and closures to finally make into the language for obvious reasons.

Outside of what you would consider mainstream enterprise languages, fire up a job search (dice again for example) and you'll see the increasing prevalence of languages with full or partial FP support (Groovy, Ruby, Python and Scala.) There are a lot of enteprise projects starting up with Scala now. I've personally been receiving more calls from head hunters for jobs requiring FP exposure than just plain Java. YMMV.

Jesus, I even recently saw a lot of openings for a major bank recently asking for Erlang or Haskell. Strange and exciting things occur in the enterprise if you look beyond the superficial. There are banks and trading companies out there actually looking for FPGA programmers to code their most time-critical business processes on re-programmable hardware. So it is really that surprising that "enterprisey" programming shops look ahead and are using FP? Better get out of that rock you've been under buddy.

And even if there was no support or hunger for FP in the real world, you miss the point that academia is not a vocational trade school. It is not supposed to devote the entire curriculum to the training of a single programming paradigm or technology stack.

A good school will introduce you to the concepts of OOP after covering the basics of programming, including historical and hands-on coverage of structured and modular programming. There is a certain level of maturity and programming dexterity required by a student to, more or less understand the concepts behind a OO paradigm.

CMU recognizes this which is why it's moving OOP to the sophomore level. By using a FP paradigm at the freshman level, it introduces the new student to the concepts of program composition, which is something far more fundamental that OO. Other schools could do somewhat differently by teaching procedural/structural/modular programming with a multiparadigm programming language: in this case, it would help the student cross the mental chasm between ADTs and modules into object oriented models.

You are simply being obtuse.

Re: don't be obtuse by Andrew McVeigh

> For starters, there are jobs out there that do require applicants to
> know functional programming.

You've fed the troll. Well done.

Re: Please help: I do not understand by Sukant Hajra

I don't want to get into a flame war, but this argument is conflating structured programming with functional programming. Structured programming all about Dijkstra's disapproval of "goto," but it's still largely imperative programming -- you are able and arguably invited to reassign the same variable with multiple values.

You aren't doing functional programming just because you have functions or methods and one calls the other. What exactly constitutes "functional programming" has slowly mutated over time, I think. There are two traditions I see. One spans decades and roots in Lisp. That tradition celebrates first class functions, but makes pragmatic allowances on immutability (and consequently referential transparency). Furthermore, this tradition isn't interested in reasoning about programs through types. This is where the second tradition comes in. Later languages like ML began exploring more what can be done with a type system on top of the functional style. And finally, languages like Haskell began to assert functional purity, emphasising immutability and creating enough isolation from side-effects to have a lot more referential transparency.

There's another problem with your argument. . . I believe it's conflating the problems solved by Spring, SCA, and OSGi with Wadler's Expression Problem. These aren't the same thing at all. What you're talking about allows for strong encapsulation behind a rigidly defined interface. Yes, these are modules, but they are extremely rigid, which limits opportunity for composition and reuse. Solutions to the expression problem allow us to have much more flexible abstractions, mixing and matching partial interfaces that are designed for composition. The problem Spring and company address is mostly a hole in Java's assembly implementation. I don't think either OO or FP is intrinsically better or worse at this; Java just sucks. What I believe Harper is alluding to is finer-grained modularity problem -- a complaint with the abstraction of an object.

Re: don't be obtuse by Luis Espinal

> For starters, there are jobs out there that do require applicants to
> know functional programming.

You've fed the troll. Well done.


If it was a troll, no biggie. If it was not and indeed believe he's right (no one should be surprised at this point that there are people with CS degrees and with work experience that genuinely and honestly think like that), then there is always hope that my post is of use for someone. Or at the very least, it should entice someone that disagrees with me to provide a thoughtful, constructive counter-argument.

Re: don't be obtuse by Andrew McVeigh

> Or at the very least, it should entice someone that disagrees with me to provide
> a thoughtful, constructive counter-argument.

alright, let me have a go at the argument that OO shouldn't be taught in the way you discuss below...

> A good school will introduce you to the concepts of OOP after covering the
> basics of programming, including historical and hands-on coverage of structured
> and modular programming

There are 2 ways to approach the teaching of OO: as a bag of technical tricks leading to late-binding, or as a simulationist philosophy. I can see the benefits of the former - it helps you understand the mechanisms. However, I subscribe to the latter, and I feel it has huge benefits. In this approach, OO isn't just a collection of polymorphic calls, but a way to model and view a system that accords (somewhat) with our understanding of the world.

FWIW: it is undeniable that functional programming jobs are on the increase. In my field, it is still niche, but definitely mainstream. There are hundreds of jobs for F#, Haskell and KDB+ (functional variant of APL) programmers. The best paid person I know maintains a functional language implementation for creating derivative payoff structures...

OOP vs. Functional is cutting it too narrow by Faisal Waris

Getting back to the original intent of this post regarding CS education...

I believe that a well rounded practitioner will have command of multiple major programming idioms - oop and functional are just two of them. Here is my list:

- functional programming
- object oriented programming
- logic programming (Prolog)
- actor model (Erlang, Scala, F#)

In addition there are minor idioms that well-versed practitioners should know:

- pattern matching (ML family, F#, XSLT, regex)
- lazy evaluation (Haskell, F# comprehensions)
- mathematical programming (AMPL)
- query languages (sql, xquery, sparql)
- rules based systems
- reactive, event driven systems
...

Each of these bring concepts (a mental model) that are applicable to specific probelem domains which one may face during the course of building a single system.

Note I am sticking to programming idioms here. There are other areas such as information modeling, process modeling, etc. that are not even on the list.

Churning out CS grads that just know java or oop would be a dis-service to the industry.

Re: don't be obtuse by Luis Espinal

> Or at the very least, it should entice someone that disagrees with me to provide
> a thoughtful, constructive counter-argument.

alright, let me have a go at the argument that OO shouldn't be taught in the way you discuss below...

> A good school will introduce you to the concepts of OOP after covering the
> basics of programming, including historical and hands-on coverage of structured
> and modular programming

There are 2 ways to approach the teaching of OO: as a bag of technical tricks leading to late-binding, or as a simulationist philosophy. I can see the benefits of the former - it helps you understand the mechanisms. However, I subscribe to the latter, and I feel it has huge benefits. In this approach, OO isn't just a collection of polymorphic calls, but a way to model and view a system that accords (somewhat) with our understanding of the world.


I happen to subscribe to the simulationist philosophy as well. I'm not sure, however, how understanding the mechanics imply the treatment (and or teaching) of OO as a bag of tricks (or it's teaching as teaching via a bag of tricks.)

I believe that learning the mechanics is important for historical and practical reasons. Mechanically and historically, OO borrows, inherits and ultimately benefited from structured/procedural/modular programming. Pedagogically, it is (or should be) unacceptable to have CS students graduate with a 4-year degree without being able to describe any of these paradigms... and yet that is the common case nowadays (despite the fact that lessons taught with these paradigms are still important in the real world.)

In the practical sense, the world and most complex models of systems in it are multi-paradigm. Paradigms that preceded OO still apply in one way or another to views or sections of systems under development. An engineer cannot possibly make sound decisions if all he knows is a hammer.

Obviously one does not want to capriciously apply every single paradigm there is to a model. However, the opposite (which is what most programmers have been living for the last 10-15 years) which is to force everything under a OO paradigm is equally malignant and ineffective. We have people who have never worked with anything other than a OOP language and yet 1) cannot describe what a good model is, and 2) cannot produce a model or solution description that is not OO-based, for situations and systems that do not require one (which is very common.) That is not acceptable.

Teaching the mechanics of OO, and the paradigms that preceded it, teaching that the concepts of encapsulation, sound structure, modularity, composition and information hiding are not specific and unique to OO is vital for a true understanding of what OO is (or what is not). This in no way prevent (nor it is mutually exclusive to) the teaching of OO from a simulationist philosophy approach.

Teaching OO as a bag of mechanical tricks might certainly prevent or negatively influence the teaching of OO from a simulationist approach. That is not what I propose, however. Teaching the basics of programming (how to program sequentially, basic algorithms and logic control structures, foundational things like the Bohm-Jacopini structured program theorem, problem analysis), history and evolution of programming paradigms (with hands-on practice), I don't see how that can qualify as teaching bag of tricks. Maybe if it is done wrong, but then that's a problem with teaching, not a problem with the subjects of study.

FWIW: it is undeniable that functional programming jobs are on the increase. In my field, it is still niche, but definitely mainstream. There are hundreds of jobs for F#, Haskell and KDB+ (functional variant of APL) programmers. The best paid person I know maintains a functional language implementation for creating derivative payoff structures...


I know. I just saw a position in dice for a Lisp programmer (Allegro CL) as well as two positions for Erlang (for the later, the hiring company was willing to take people with Haskell experience instead.) Good, good salaries, enough to make one wonder about a programming language career change.

Re: Please help: (no need to panic) by jean-simon Larochelle

Despite its limitations OOP is a great technique that has brought tremendous productivity gains to programming. I remember the first Borland IDE based on TurboVision (an OO text based framework for UI). On the PC this was a huge step forward and was followed by graphic OO framework under Windows (ultimately Borland VCL).
Also, from the moment we started using OO we got a tremendous gain as far as reusing code was concerned (despite what some people are saying). Switching to the "evil Java language" was another big step forward for us.
Just make sure you read about OOP and learn the craft. Not the place to list everything here but things like:
Avoiding:
- deep class hierarchy
- public data members and in Java for example protected data members
Maximize:
- Immutable objects
Pick up a good book and read about it (OO) and make sure you learn about mutlithread programming.
Read a good book on functional programming.

Re: huh? by Dean Wampler

> I don't really understand how the 2 paradigms can be completely reconciled at their core. If the starting point of objects is that they encapsulate mutable state and operations on that state, and the starting point of functions is mathematical composition over immutable data, what is the common viewpoint?

They can only be fully reconciled if the objects are immutable. Scala, for example, tries to merge the two paradigms, allowing you to land on the spectrum somewhere between pure OO and pure FP, as you see fit. I should emphasize that FP doesn't mean throwing away good type design (depending on the language...). Pure FP languages don't have OO-style inheritance of types, of course.


> I think these concepts are possibly applicable to functional systems also - in those systems, don't you get complex compositions of functions, where reuse mandates a change in a function at the bottom of the tree also?

The immutability and side-effect free functions in FP are the secret sauce of composability, I think. Otherwise, you quickly hit a wall of complex state management that makes it very hard to ensure robustness, which is what we see in a lot of production software systems.

Re: Object Thinking by Carlos Silva

Some books we regret not having read when they were published. This one I just finish last week and was doing this kind of highlights to use on discussions like that.
Thank you, you did! "The People Issue", that's the problem with bad use of any languages or way of thinking in programming systems.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

42 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT