Aspects versus modularity

Today at OOPSLA, I sat in on a panel discussion on aspect-oriented programming. It was about whether aspects are a good thing, when to use them, or whether they can help achieving modularity in our applications. One comment, which is more on aspect tools rather than the principle of aspects, was that aspects are a fix for something that should be included in a language or platform in the first place. One discussion was about exactly what aspects should be used for. The people opposed to aspects challenged the advocates to name killer apps of aspects. The best killer app they came up with was Spring where aspects are a central component to provide an alternative enterprise container for Java.
A lot of discussion was about whether that aspects would make the application code unreadable because functionality is implemented in aspects and thereby “hidden” when looking at the code. As a conclusion, the panelists argued that aspects should never change the core application functionality. Whether this is the case when it comes to Spring, I have some doubt.
My conclusion from the panel discussion is that it is not certainly clear what aspects should be used for, except maybe for logging purposes. Furthermore, I am not content with the argument from the advocates of aspects that aspects bring to the table that cannot be implemented in programming languages.