I've been writing about Moose in the Modern Perl book draft recently. Moose is clearly the right way to teach object orientation in the context of Perl 5, and I've enjoyed how Moose makes doing the right thing easy.
Yesterday I explained inheritance in the context of Moose and Perl 5 OO.
I'd already explained Perl roles. If I didn't have to acknowledge that people reading the book will eventually run across legacy code, I could happily gloss over inheritance as an idea that turns out to be much less useful than it first appears. I suspect that inheritance seems great to OO novices because it's spectacular and interesting: code appears seemingly for free out of nowhere! That's easy to understand, while the subtle utility of polymorphism and parametric polymorphism require you to have struggled with the problems they solve so you understand their value.
Would so many of us appreciate Moose if we hadn't wasted so much time doing things the hard way?
I spend a lot of time thinking about how to teach people to appreciate and to understand modern Perl in ways that do not lead them down the dark alleys and bumpy roads where I had to learn to program the hard way. I'm very stubborn, and I'm perfectly comfortable taking apart something to figure out how it works. (The people who fix bugs in your favorite programming languages likely share this trait.)
I don't believe that attribute is a necessary precondition for learning to program well.
However, I do wonder if it's more difficult to understand the value of a non-obvious system until you realize the drawbacks of the system you do understand. I've seen novices insist that they absolutely must use symbolic references instead of hashes, or that manual iteration instead of list transformation is so much easier, or what have you that I wonder about the diactic value of trying to show people the best general approach as I understand it now first, then mentioning other ways that aren't as good.
Consider an example. I know better ways to write Test::Builder because I've implemented it three times now, in Perl 5, Perl 6, and PIR. I like to think I'd have listened if someone suggested infelicities in its original design, but only the experience of implementing and using it helped me to understand what it really needed to do.
I wonder. Is it possible to teach Perl 5 in such a way that novices don't have to suffer all of the miscues that the rest of us have in the past decade? If so, how do I do that? (If not, what does that imply about new adoption of Perl 5 and adoption of Perl 6 in general?)
Maybe I'm conflating learning a language with learning how to design programs—but how do you separate the two when your goal is merely to teach people how to solve problems?