Smalltalk-80 decomposed program execution into an artful collaboration between objects waiting for only the most interested to discover.
Smalltalk was a great environment to explore in the 80's because it was already 10 years old but still amazingly simple and self-consistent.
For example, I had cooked up a diagram notation that was useful for explaining division of responsibilities between mutually dispatching objects. One day, in casual conversation, we asked, "what browser or inspector already knows enough to draw these diagrams for us?" The fact that we could even pose this question says something about the intellectual integrity present in the system.
After a few minutes thought we realized only the debugger knew enough to capture the trace nature present in my diagrams. We turn immediately to the source code and found the method:
aContext interpretNextInstructionFor anObserver
There it was. All of the complexity of object-oriented program interpretation separated into functional parts. The debugger was just one observer present in the system. Other callers included a simulator and a code formatter. We subclassed Debugger as DiagrammingDebugger and then added what we wanted to the screen.
The CASE'87 paper described this and another tool we built for ourselves and used every day. Kent flew to Boston and presented. The attendees showed absolutely no interest in this work. The fact that any programmer should need to understand anything was not within the "computer aided software engineering" agenda.
CRC Cards were another manifestation of the same thing: how to think about programs that share responsibilities.
We later contextualized this to software patterns. What are the divisions of responsibilities that we see all of the time.