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?
Having spent nearly four years on #moose, even when people have a decent grasp of Moose and Roles and Inheritance ... there are still a million things to re-learn.
You have to show the counterexamples. Or you have to pose real-world problems that reveal the deficiencies of a particular approach. Or, as happens in school settings, you have to have problem sets and projects that are simplified and yet instructive.
I remember my first college level C programming assignment: write a text editor with Curses. And then the class got to debate pros and cons of the approaches people took afterward.
The problem I have with most introductions to OO is that the examples are so stylized (shapes, animals, etc.) that it's hard to understand why things should be done one way and not another.
One of the things I really liked about the Definitive Guide to Catalyst is that it uses a simple but real example end to end. That's rare for a book on programming.
On Moose, since I've been struggling up the learning curve lately, my early impression is that I do love the power and flexibility of it, but it's very easy to get lost in a thicket of Roles. For the first time in a long, long time, I've wanted an IDE to help me figure out all the things affecting a method call. Method modifiers are a real hurdle to quick code comprehension.
-- dagolden