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.

Re:Hmmm ...

[mellon]

I don't know about *starting* in assembler, but a programmer who isn't somewhat proficient in assembler is going to have a very weird mental model of how programs work. OOP has the same problem--it's not that OOP is bad; it's that if you start out with an OOP language, you don't learn a lot of things that are important to understand. Once you know how the machine works, then you can start studying abstraction. Treating OOP as the only way, or even the best way, to solve any computing problem is going to tend to produce programmers who think everything is a nail. It doesn't mean that there are no nails, nor that students shouldn't learn to swing a hammer.

Computer scientists?

[DNS-and-BIND]

Why are computer scientists even learning programming? When did this happen? Programming sounds like one of those get-your-hands-dirty jobs in flyover territory, where you would show a lot of ass crack on the job and live in a trailer park. Educated people don't do that.

Re:Computer scientists?

[WrongSizeGlass]

Why are computer scientists even learning programming? When did this happen? Programming sounds like one of those get-your-hands-dirty jobs in flyover territory, where you would show a lot of ass crack on the job and live in a trailer park. Educated people don't do that.

They need to be able to program for the same reasons management and engineers need to spend some time on the assembly line: so they can learn how things actually work. There's often a wide chasm between "on paper" and "in practice" and ideas need to be able to traverse it.

Why remove it?

[Haedrian]

I don't see why it should be removed, it should be 'complimented' instead with other programming methodologies in order to let users compare and contrast. But most CS in the end will end up being done with OOP so there's no reason not to start in the beginning - at least that's my personal experience.

In my first year we had a mixture of different programming types, including functional programming. I never really used any of those, I'm sure there are certain places where Prolog or Haskel is used, but its not as common as an OOP.

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

[digitig]

Sure your classes have methods. But good OO design says that your classes correspond to groups of real-world objects: bank accounts, people, widgets, whatever. Why? Because that is the data that needs to be processed.

That seems to be a fundamental misunderstanding of OO. The focus on real-world objects is because they have self-contained properties and behaviour. "Because that is the data that needs to be processed" is no more (and no less the case) than Because that is the behaviour that needs to be produced.

The methods are tied to the classes, meaning that their very definitions depend on the data modelling you have done.

Or (and just as valid), the members are tied to the classes, meaning that their very definitions depend on the use cases (ie, actions) you have identified.

Working this way is suitable when you are dealing with complex data and comparatively simple algorithms; get the data model right, and your problem is half solved.

You do realise that data model != object model, don't you?

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.

Radar data was a bad example. A modern radar processing system takes data from many sources such as primary radar heads, secondary radar heads, ADS-B, ADS-C, WAM, neighbouring radar processing systems and so on. These behave the same in most ways but differently in some, and OO turns out to be an excellent way of dealing with that.

Yes, in some applications OO doesn't offer you anything significant. They are typically the cases in which you end up effectively with one class because the data and the processing are so simple. But in this context "simple" processing doesn't mean mathematically or computationally simple, it means that you only do one thing with the data (in the case of the radar front-end, for instance, the one thing will be extracting distinct decluttered returns into distinct objects for passing to the next processing stage). OO design still doesn't get in the way, though: if that's the only thing going on in that process you simply end up with a design with only one class having only one significant method (so if your language supports it you might just as well write the lot as a single routine with no class packaging).

For what it's worth, I have no problem with OO not being taught from the outset on a computer science course. It's a decompositional/compositional approach and is not a lot of use until you understand what you are decomposing and composing.

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.

OO a tool for craftsmen, not comp sci

[shoppa]

Focusing on the basics, and not on the tools of the trade, is very important at something that is not a "trade school", and CMU's computer science department certainly lives above the trade school level. (Just to contrast: when I was a freshman, the "trade school" argument was whether new students should be taught Fortran or Pascal ! Thank heaven I didn't devote my career to being a programmer.)

It seems to me that CMU's made the very obvious decision that today, OO is a tool for craftsmen, not for freshman computer scientists. And they probably are right. It's important to not confuse the tools of the trade, with the basics of the science, and this is especially true at the freshman level. For a good while (going back decades) OO was enough on the leading edge that its very existence was an academic and research subject but that hardly seems necessary today.

In the electrical engineering realm, the analogy is deciding that they're gonna teach electronics to freshmen, and not teach them whatever the latest-and-greatest-VLSI-design-software tool is. And that's a fine decision too. I saw a lot of formerly good EE programs in the 80's and 90's become totally dominated and trashed by whatever the latest VLSI toolset was.

Re:OO a tool for craftsmen, not comp sci

[hey!]

Well, I'd agree with you if you this were a class in an O-O language, but it's a class in a major programming *paradigm*. And even theoreticians have to express themselves in code. If the summary is to be believed, the department is taking a stand against O-O programming based on what it sees as the paradigm's shortcomings. Let me tell you, thirty years ago you'd hear the same kinds of arguments in a computer science department about how bad virtual machines were. Virtual machines were an early, failed attempt at getting around the limitations of early compiler technology. C showed you could have a language which was nearly as fast as assembler (faster for most programmers), and easily portable across architectures. There was no reason to study virtual machines, they had no practical application. Well, it probably would have been a good idea to have them in the curriculum somewhere to study on a theoretical basis, because ideas in computer science have a way of re-emerging.

Computer science as a discipline embraces topics other than the theory of computability and complexity theory, which might as well be taught in the mathematics department. For example there is computer language design, hardware architecture, data communication theory, database theory, AI etc. Some of these could be put into other departments, I suppose, but an understanding of the core intellectual discipline *is* widely applicable to all the topics that commonly fall under the "computer science" rubric.

I think an empirical case for separating computer science from software engineering might have sounded convincing fifteen years ago, but Google, and the Internet in general, are strong disproofs of this. Google isn't a search company. It's an algorithm company. It's about doing things on a scale so massive it requires serious computer science ability, well above the "tradesman" level of expertise. Which is not to say that what it does is as "pure" as the work an academic interested in computability per se and defining new kinds of complexity classes, but that kind of work, isolated from its applications, is of such narrow interest it hardly justifies the existence of a department separate from the Mathematics department.

I do see the need for separate concentration areas or departments for computer science per se, software engineering and information science, although having employed a number of people with Masters' degrees in information science I have grave doubts about the academic quality of degree programs in that field. An academic degree should give you the intellectual tools to think about a problem, not necessarily the practical tools to work on it, which can be picked up other ways. The O-O paradigm fits into this framework. The requirement to learn a specific O-O language like C++ or Java is a different matter; somebody with a degree in C.S. should be able to pick any such language up because he should understand the *design* of the language.

I suspect we're seeing departmental politics here.

A larger problem

[wootest]

The big problem with OO courses has always been that there's far more focus on the mechanism (and, lately, on design patterns) than on actually structuring your program to take advantage of objects. The word "polymorphism" isn't as important as getting across the concept that you can coordinate a few things as if they were the same thing, and have them act in different ways. Knowing a bunch of design patterns by name isn't as important as figuring out once and for all that you can structure your program in such a way that you can create interfaces (not necessarily actual interfaces/protocols) between different parts of your program and essentially replace them, or at least rework them entirely without having the whole house of cards collapsing.

There's no focus on making it click. There's no course that teaches you explicitly just about formulating problems in code, and that makes me sad.

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.

Re:Hmmm ...

[immaterial]

Given its toxicity to humans, I recommend avoiding drinking from the holly grail altogether.

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Really?

[Fnord666]

Perhaps I'm misunderstanding the post... it sounds to me like OO techniques are only going to be taught in elective courses from now on. If that's the case, I think CMU is missing the fact that the majority of development work in the "real world" is done on already-existing platforms. Parallel/cloud computing and modular design may be the "next big thing", but what happens when the student gets their first job working with an application built with Java or .NET? Maybe in their ivory tower they can say "OO is dead" but in the real world, OO is very real.

This is a CS program we are talking about. Much like economics, in these disciplines the real world is often considered a special case.

Re:What?

[Anonymous Coward]

The point of a university Computer Science course is not to train students in iPhone development.

Re:Hmmm ...

[salesgeek]

Um. No. Many modern libraries or "frameworks" (newfangled word for library) are OO. Most OSes remain written in classic system programming languages like C and assembly language. In fact, most frameworks start as object oriented wrappers for certain OS calls and cruft up from there.

Re:What?

[osu-neko]

Perhaps by not quitting after their freshman year, and learning some OOP?

Re:Hmmm ...

[osu-neko]

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

And how is this an argument for including in the introductory, freshman curriculum? I put forward the possibility that some topics may be more appropriate to be taught to students only after they've learned the basics.

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

[CptPicard]

I actually have never believed that assembly is in any sense informative or educational because "it is how the computer works". It's actually a remarkably hard to decipher representation of a program, and what the program is and does is the important part.

I consider myself quite a strong programmer, and I never think in terms of assembly when writing programs. Higher-level languages, in particular functional programming languages, are far closer to my mental model of things. Why not work in a language that represents or helps formulate the problem-space abstractions better?

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

[Dails]

I outright laugh at people in an Interview when they ask me if I'll write OO code.

Good advice for those seeking work.

If you can't read straight up C code and understand what the fuck is going on, stop calling yourself a programmer.

They used to say that about assembly. Try writing a modern game or GUI in assembly. You might well be able to do it, but by the time your'e done I'll have finished several projects and be moving on to the next one.

If you can't code directly for the hardware you're interfacing with, stop calling yourself a programmer.

Right. Abstraction has no place in computer science education or in programming. As a matter of fact, if you're using anything other than a magnetized needle to right to your hard drive, quit calling yourself a computer user.

If you depend on .NET, any library, framework, or something written by someone else, you're not a programmer. You're a script kiddy.

Right. Code reuse is so lame. Anything that reducing development time and improves efficiency has no place in computer science. Everything should be written directly in binary on a computer you, the programmer, built from latches, switches, and flip-flops. Otherwise, you're just a bum.

OO should never be taught lest we end up with a generation of useless tools who think they're "programmers" that can't actually accomplish fuck all

Right. After all, every program written using OO is useless and nonfunctional. Except for the hundreds of thousands of programs that work just fine.

Go back to your garage with your unflinching dedication to The Old Ways and leave the rest of us to be productive.

Re:Hmmm ...

[Duradin]

So you can't call yourself an english major if you can't read Sumerian cuneiform?

Re:Hmmm ...

[chthon]

While I also disagree with the tone of the parent, I hope you understand that abstraction and code reuse are not features that originate solely from OO programming? It is enough to have a module or package mechanism.

Re:Hmmm ...

[wmbetts]

Yes it produces more powerful methodologies, because of the synergistic effects that objects have with modern cloud environments.

Re:Hmmm ...

[chrysrobyn]

I consider myself quite a strong programmer, and I never think in terms of assembly when writing programs. Higher-level languages, in particular functional programming languages, are far closer to my mental model of things. Why not work in a language that represents or helps formulate the problem-space abstractions better?

In a word, performance. In your particular field of expertise, performance and memory footprint may not matter (99% of desktop applications I suspect), but a strong programmer is fully aware of what goes on under the covers when [his|her] program is compiled to the degree that it impacts the product. Until recently, I never thought there was a functional difference between a lone line containing "i++;" "++i;". Of course, for variable assignment it matters, but what's going on under the covers? If you stop and think about it, i++ actually has to return the old value. ++i can destroy that old value and never needs to worry about returning the old value (you can avoid an extra copy). If you're in a high performance loop, either with not much body or with a lot of increments, such things matter. Understanding the impact of caching, the scarcity of registers, the high cost of flushing the cache, all of these can matter, and it's hard to teach these concepts without using at least a pseudocode that looks suspiciously like assembly. If you're paying for compute cycles, or if you're selling something in a market where performance matters, you're going to see a strong advantage in a computer scientist who understands assembly and compiling.

Now, if your main concern is code readability, maintenance and/or moving onto the next product as soon as this one compiles with no errors, higher level languages are undoubtedly far more appropriate.

Re:Hmmm ...

[Just Some Guy]

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.

That's called "managing expectations", and is a wonderful introduction to their future careers for a lot of CS grads. Now go fetch me some coffee while this build finishes, would you? Thanks.

Re:Hmmm ...

[siride]

You are still probably doing OO on some level even in C. OO is not a whole different paradigm, but is rather an institutionalization, so to speak, of a variety of patterns that are already used in procedural programming, with its own additional "enhancements" (for better or for worse).

I don't think the difference in job markets between C and Java really has a lot to do with OO as a methodology. It probably has more to do with what's available on what platform and what companies are using those platforms (more importantly, what *kind* of companies are using those platforms).

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.

Re:Hmmm ...

[IICV]

Until recently, I never thought there was a functional difference between a lone line containing "i++;" "++i;". Of course, for variable assignment it matters, but what's going on under the covers? If you stop and think about it, i++ actually has to return the old value. ++i can destroy that old value and never needs to worry about returning the old value (you can avoid an extra copy).

Isn't it great that we have optimizing compilers that'll take care of considerations like that for us?

A.. code should be written for clarity first, and if it turns out that it's not quite fast enough only then should you start worrying about whetehr or not it should be i++ or ++i.

Another CMU Perspective

[JonathanAldrich]

As some readers may have guessed, "anti-modular," "anti-parallel," and "unsuitable for a modern CS curriculum" are one person's opinions, and do not represent the majority view of the CMU faculty. The introductory curriculum was changed away from Java for different reasons: primarily to focus on a language (Python) with simpler syntax and dynamic types, and to supplement with material on C that is closer to the machine. For more details, see a report by the SCS Deans:

http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf

Whatever you may think about delaying OO--and opinions are mixed at CMU as everywhere--one advantage of the new curriculum is that the sophomore-level course can do OO design more justice than we were ever able to do in the prior intro sequence, since the students already know how to program. Modularity and parallelism are in fact major emphases of that course, which I and other CMU faculty are currently developing.