They just needed to get used to thinking in terms of objects (which actually quite amazes me - because, in my mind, we deal with objects every day outside the context of programming, so why is it such a tough sell inside programming?)

Because the concept of an object in programming is not closely related to the concept of an object in the real world. The concept of an object in programming is related to the concept of an object in math. People who have not had math beyond the secondary level tend not to have been exposed to the concept of an object in this sense at all.

The exception is the way objects are typically used in the Inform programming language. Now, Inform objects *are* programming-concept objects, and can be used as such, but in a typical Inform program, an Inform object represents a real-world object, such as a chair or a box or a door. This is a consequence of the problem domain, but it makes an *excellent* introduction to OOP, because it builds on something people are already familiar with and then introduces programming concepts to it (properties and so forth).

I don't think this could be handled in the same way with the Perl object model, however, because the Perl object model (even, as near as I can tell, in Perl6) does not provide the object forest, which really is essential for elegantly dealing with Inform's particular problem domain (i.e., the chair is in a certain room, and the player can set the box on the chair (because the chair has the supporter attribute) and place the amulet in the box, and so forth, and that containment tree is built into the object model at the vm level as well as at the language level; it is, incidentally, generally useful for other kinds of problems as well.)

When you program in a language like Inform, where the objects represent real-world objects, you see how *different* traditional programming objects are from objects in the real world.