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.

The objection that AOP is unstructured becase it injects arbitrary code into your function is common, and it's absolutely correct if you consider editing code in a plain old text editor.

In reality, almost no one does this. Because of the nature of AOP, it requires IDE support--see the AJDT (http://www.eclipse.org/ajdt/) for one example of what this looks like.

With IDE support, you can see exactly where aspects might affect your code, and you can easily navigate to the definition of these aspects. Tool support essentially gives you the desired scoping back, even though it's missing in the language.

Gregor Kiczales and Mira Mezini have a nice paper on this (http://www.cs.ubc.ca/~gregor/papers/kiczales-icse 05-aopmr.pdf), and I've done some more theoretical work validating the claim that modular reasoning is possible in AOP, given the proper module system and tool support (http://www.cs.cmu.edu/~aldrich/papers/open-module s.pdf).