I agree completely. I was responding to your suggestion that once objects are available, nested hashes are no longer useful.

I have had the misfortune of working on systems many times where internalized data management with limited scope was implemented using objects because everything must be an object. The resulting mess was much harder to maintain than any temporary structure would have been.

I've also been bitten by extremely complex protocols developed for the sole purpose of passing around objects that needed to be compatible across languages or versions. A simple list of hashes or hash of hashes might have been a better choice.

I'm not suggesting that hashes are better than object, they are just another tool we have available. The key is to understand the trade-offs. While I have certainly been in the situation you describe, I've also done time in other environments.

Objects don't necessarily solve the naming problem completely. What do you do with an interface that contains the methods find_object, get_object, make_object, create_object, and find_and_create_object (example anonymized from real code). At best, objects can reduce spelling errors by making them compile errors. But, making a badly-designed hash into a badly-designed object isn't really an improvement.

Until I tried to explain this, I hadn't really thought of using hashes on simple problems to help teach object design. It's sometimes easier to focus when the rest of the mechanics isn't in a student's way.