CMU Eliminates Object Oriented Programming For Freshman

fatherjoecode writes "According to this blog post from professor Robert Harper, the Carnegie Mellon University Computer Science department is removing the required study of O-O from the Freshman curriculum: '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.' It goes on to say that '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.'"

Comments

so the wheels are coming of the OO band wagon then

[mjwalshe]

I always thought the obsession with making everything OO when it doesn't suit every type of programming problem was a bad thing - glad to see some one agrees with me.

Interesting move

[bradley13]

OO is practical for lots of problems, because it makes modelling real-world data easy. However, it is not useful if you want to give students a solid understanding of the theoretical computer science. OO is fundamentally data-centric, which gets in the way of algorithmic analysis.

To give a pure view of programming, it would make sense to teach pure functional and pure logic programming. If CMU really wanted to concentrate on the theory, they would have eliminated imperative programming from the introductory semesters, because it is very difficult to model mathematically. Apparently that was too big of a step.

Re:Interesting move

[digitig]

OO is fundamentally data-centric

Maybe the way that you do it. Personally I find that quite a lot of my classes have methods.

If CMU really wanted to concentrate on the theory, they would have eliminated imperative programming from the introductory semesters, because it is very difficult to model mathematically.

Imperative programming isn't really any more difficult to model mathematically than functional programming. They just use different branches of mathematics. Check out David Gries's The Science of Computer Programming for example, which shows how to do it, and Object-Z which actually does it. The main difficulty is with side effects, but functional programming has the same issues as soon as you try to interact with the external world.

Re:Interesting move

[khallow]

The other situation is where you have complex algorithms, but simple data. Signal processing, control software, scientific programming, etc.. Take a radar as an example: the data is just a continuous stream of numbers coming in off the radar dish; but the algorithms that extract meaning from those numbers are very sophisticated. Using an OO language for problems like this is like trying to loosen a screw using a wrench - maybe you can make it work, but it's basically a really bad fit for the problem.

I nodded at first when I read this, then I realized, the complex algorithms are objects in themselves. And the "simple data" usually has structure and meaning to it. I have some experience trying OO approaches to scientific computing. A naive approach can result in some awful problems that add little to the fundamental work.

My personal experience has been with writing matrix algorithms. The conditions of the matrices were that they were "large" and usually had nice internal structure (for example, a class structure might be rectangular matrix, upper/lower triangular matrives, diagonal matrix, and constant matrices, constant diagonal and the zero matrix). They are "simple" data sets, but a little insight into their structure can result in significant savings in data stored and the cost of common matrix operations (like matrix multiplication).

For me, I ran into some deep problems when I attempted to operate on multiple matrices with structure. For example, suppose in addition to the list mentioned above, I create a new class type for block diagonal matrices. There were already six matrix classes. So if I want to do matrix multiplication, I have potentially 13 new pairings of classes (left or right multiplication by block diagonal matrix on the six existing classes plus multiplying two block diagonal matrices together).

For my language choice, C++ (and later Java), I couldn't just implement matrix multiplication as a method. I know there's some stuff with better OO implementation out there, but that's what I was using. So I ended up representing matrix multiplication as its own object, and registering specialized multiplication algorithms in a poset structure. When two matrices need to be multiplied, the matrix multiplication class looks up all the specific algorithms that would work and picks one with the best heuristics.

Whether the complexity of that overhead is justified, well, eh... never did finish it. All I can say is that what I implemented, allowed me to throw stuff together without thinking too much about the internal structure or taking a huge hit on computation (given what I was doing, PDE difference method modeling and least squares stuff on large piles of data).

But this example steers my intuition here. You may have several competing complex algorithms. You may end up changing the structure of the simple data you operate with. The places where your scheme can change are places which you can and maybe should objectify. Also you have processes which you can abstract through objects, for example, if you are piping data through a DSP system, then a stream structure with filters applied to the stream in sequence might be a suitable abstraction for what you're doing.

Re:Hmmm ...

[WrongSizeGlass]

Agreed ... but aren't most modern OS's OO based? In most cases students need OO programming in order to become employable. OO certainly isn't the holly grail of computing but it is entrenched in business and needs to be taught just like COBOL was all those years ago (when I had to learn it even though it was like writing a book every time I wanted to write a small program).

Anti-Modular?

[msobkow]

Apparently the meaning of "Modular" has changed since I was in University back in '82. OO used to be the epitome of modularity.

But I do agree that making it an introductory first-level course does warp the mind of the young programmer. There are a lot of languages that don't enable OO programming at all (e.g. Erlang), which become much more difficult for them to grasp because OO is so engrained in their thinking.

I can't think of anything specific about OO that makes it poorly suited to parallel programming. There are languages whose nature is parallelism (again, Erlang), but that's usually accomplished by adding parallelism operators and messaging operators to a relatively "traditional" language. I don't see why you couldn't add and implement those constructs in a non-parallel language.

I also shudder to think how a CS student is going to deal with parallelism using languages that don't make it a natural extension if they're learning to rely on those extensions in their first year.

I gotta tell you, though, I really object to the use of Java as an introduction language for programming. Java is far from a shining example of any particular style of programming. It's not real OO because it's only single inheritance. It's not designed for parallelism. It doesn't have messaging built in. In short, Java is actually a pretty archaic and restricted language.

Re:Anti-Modular?

[jameson]

Yes, there has been much progress in module systems. The very Bob Harper mentioned there was involved in the design of the SML module system, which is often cited in the CS literature as `the' reference module system. SML achieves a level of isolation that is simply impossible to achieve in a language like Java or Smalltalk. in Java, any object you can still call `hashcode()' and `toString()' etc. on, and it's often possible for someone to subclass one of your internal classes and thereby break your intended module structure.

In SML, you can confine types through (e.g.) the following signature:

(* this is imperative code; a typical SML program focuses on functional code, but it's good enough for illustration purposes. *)
signature STACK =
sig
    type 'a stack (* 'a is a type parameter, so "'a stack" is what OO-land calls a `generic type' *)
    empty : unit -> 'a stack (* create fresh stack *)
    push : 'a stack -> 'a -> unit (* take a stack of 'a elements, take an element of type 'a, and plug them together *)
    pop : 'a stack -> 'a option (* "'a option" means that the operation may fail *)
end

You can then implement this stack in various structures that match this signature, and confine it in such a way that only the operations listed above are available. That is, you can't stringify stacks (there is no such operation listed there, though you can choose to add one), you can't compare them (again, no such operation), you can't `reflect' on them and you can't access their `protected' functionality by subclassing them, unless the stack implementer put a separate view of the structure into place for that particular purpose.

Why is this good? Client code won't end up using features that you didn't want to expose. Why is it bad? If you forgot to expose something important, someone else will have to re-implement it. But that's your fault, then, not the language's fault.

SML also allows you to build modules from other modules through something called `functors', but let's leave that for another time.

Now, SML's modules have issues-- you can't have mutual dependencies between them (which does have advantages, too, though), and the question of how to integrate type classes (something you may know as `C++ concepts') is unresolved. But the concepts behind the module system are clear and powerful. So if you want to teach the concepts underlying modular software design, this is a vastly better choice than most other options out there. (I remember the Modula-3 module system being fairly good, too, but not quite at this level.)

So, for teaching purposes I'd say Bob Harper is closely connected to the best system out there that has actual working implementations tied to it.

OOP in freshman year

[janoc]

From the position of someone who used to teach basic programming courses to freshmen, I can only applaud the decision.

Many kids coming to colleges these days do not have any programming experience or a very shaky one at best. Picking up concepts like classes, inheritance, the entire idea behind OO modelling is difficult if you are lacking basics such as how memory is managed, what is a pointer, how to make your program modular properly, etc. From the course description they are going to use a subset of C, I think that is a good starting basis for transitioning to something else (C/C++/C#/Java/... ) later on.

What is worse, many of these introductory courses were given in Java - producing students who were completely lost when the black box of the Java runtime and libraries was taken away - e.g. when having to transition to C/C++. We are talking engineering students here who could be expected to work on some embedded systems later on or perhaps do some high performance work. Even things like Java and C# still need C/C++ skills for interfacing the runtime with external environment.

I think it is a good move, indeed.

Re:OOP in freshman year

[DCheesi]

I agree that OO in the 101 course is a little much. You should really be focusing on simple programming techniques that a non-major might encounter when, say, writing a batch script or macro. I'm not sure about the second semester courses, though, since those are more for potential majors. Certainly at some point a CS major needs to be exposed to OO, but I don't think it needs to come first.

As for understanding the infrastructure, I do think C/C++ get you closer, but in my experience it doesn't really click until you take some kind of computer architecture course or similar. For instance, I didn't *really* understand pointers until I understood how values and addresses are stored in memory.

Re:OOP in freshman year

[stefski66]

What is worse, many of these introductory courses were given in Java - producing students who were completely lost when the black box of the Java runtime and libraries was taken away - e.g. when having to transition to C/C++.

What is worse, many of these introductory courses were given in C/C++ - producing students who were completely lost when the black box of the C/C++ runtime and libraries was taken away (stl, libstdc++, libc, stdlib/malloc) - e.g. when having to transition to Assembly.

What is worse, many of these introductory courses were given in Assembly - producing students who were completely lost when the black box of the Assembly runtime and libraries was taken away (OS virtual mem) - e.g. when having to transition to an OS-less embedded machine.

What is worse, many of these introductory courses were given in Assembly on powerful CPU - producing students who were completely lost when the black box of the runtime support was taken away (CPU mem protecion, FPU) - e.g. when having to transition to a simpler CPU.

Point is: whatever the language, it always come with support that you don't want to cope with in 95% of the case. Garbage collection (a la java) is one of these. Mem Protection, FPU, virtual memory (remember handles in MacOS before X ?) etc. I don't want to re-implement them, thanks.

Re:Hmmm ...

[Assmasher]

If it means they stop doing everything in Java throughout their education, I'm all for it. There's nothing wrong with Java, and I use it often in my current company, but kids in school need to learn from the get go that languages are tools in a toolbox - use the right tool for the right job when you can. I can't remember the last time I interviewed a graduate who had used C++ or C outside of a single survey course on the language! Hell, I can't remember the last time I interviewed a post 2000 graduate who had built their own processor or had even taken an assembly class. The kids are just as smart, just as eager, but woefully unprepared. The one thing they are getting a little better at is included some 'software engineering' into the curriculum - but only a little bit better in that they do 'projects together' which in my experience means that the alpha nerd does 90% of the work and the other 4 team members offer worship and keep the ramen coming.

Re:What?

[Svartalf]

Ah, but in the same vein... CS classes aren't supposed to train them for the "real world" their first semesters. SERIOUSLY. Do keep in mind that CS is really a branch of theoretical mathematics (I should know...I studied CS and made the leap to Software Engineering...) and in order to grasp the actual study, you need more than just being trained for the "real world" (If you're wondering why I'm putting that in quotes, there's a substantive (dare I say a small majority...) of development work that just simply can't use Java or "pure" C++ and there's a nearly as large subset of programming that cause more problems than they're worth because it requires REAL skill doing the task in Java or "pure" C++ and many, many of the train wrecks are caused by someone using the wrong tool because they don't understand how the tool actually works- they were trained for the "real world" by their college in a CS or Software Engineering degree and they were ill prepared to make the right decisions.). Quite simply, you teach fundamentals first, then you branch off into functional and OO programming after the fact so they understand all the tradeoffs and actually can be theoretical mathemeticians or software engineers at their discretion.

Re:Hmmm ...

[NoOneInParticular]

I think that CMU's point is that in a world where serial speed is stagnant, but where computers will become increasingly parallel (thousands of cores), a methodology that tightly links state and function, and which main mode of operation is to mutate state (i.e., OO) is not a likely candidate to stay dominant.