Spotted in Incipient(thoughts) - I ran across this explanation of teaching OO (Java, in this case, but that's not that relevant):

For instance, based on previous experience with students who had a similar background, I knew I might need to explain how the call stack worked, before introducing heap allocation as a further complication. I showed the slide with a picture of the stack and asked if that was familiar. People nodded. I wrote, in near-Java, a recursive implementation of "factorial" on the flip chart - and asked if that would work. One student said, "Not it won't - you'd need an extra static variable, wouldn't you ?"

So I walked through one specific call to factorial, showing how stack frames were allocated, where intermediate values of the parameter would be go, where intermediate results would go, and so on. Some of the students knew this stuff from CS classes, some of them even remembered parts of it - but I needed these notions, and the visual representations that go with them, to be in the "active" part of their memory while we'd be looking at more specifically OO notions, such as object construction (which involves dynamic allocation, which involves contrasting the stack and the heap, and which also raises the question of the difference Java draws between "primitive" and "object" types).

The question in the title arises from how Russ Pencin used to answer implementation detail questions in the Intro to Smalltalk class back at ParcPlace. Explaining the stack? That has less than nothing to do with teaching objects to a new group of students. I taught Smalltalk classes to many, many Cobol students, and trust me - the stack just didn't come up other than an explanation of what you saw in the debugger.

Getting bogged down in that level of detail does a huge disservice, IMHO. It's not useful, and doesn't have anything to do with the kinds of day to day business apps that ex-Cobol developers are going to be writing. teaching OO concepts has less than nothing to do with explaining the way the stack looks, or how objects get allocated in memory. As Russ used to ask me - Why do you care? A side point - if Java makes you care, then there's a very large problem inherent in Java.