Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^12: OO automatic accessor generation

by Anonymous Monk
on Nov 13, 2009 at 20:57 UTC ( #807057=note: print w/ replies, xml ) Need Help??


in reply to Re^11: OO automatic accessor generation
in thread OO automatic accessor generation

just look at like the last 2/3rds of Damians OO book, it is full of overly clever tricks that should never be done in the real world. At some point people just need to get work done.

Maybe it's been a while since you actually read Damian's OO book, because that's not how it seems to me.

Of the 14 chapters, the first two give good general introductions to the concepts of OO and the bits of Perl you need to understand to understand OO Perl. The nest five explain the basic way Perl OO works (though Chapter 5--on blessing non-hashes--has a lot of stuff that most developers would never need). Chapter 8 explains two outdated approaches to class creation (i.e. earlier and more easily understood versions of what Moose does now). Chapter 9 explains ties (which certainly are overly clever). Chapter 10 looks at operator overloading (and the last third of the chapter actually counsels against clever tricks). Chapter 11 covers several outdated approaches to encapsulation (which I know you don't consider important, but some of us do). Chapter 12 works through a simple example of polymorphic design. Chapter 13 looks at multiple dispatch (a "trick" so useful that it's now fundamental to, and used everywhere in, Perl 6). The final chapter shows a whole lot of definitely overly clever tricks for creating object persistence mechanisms.

So there are clearly "overly clever tricks" in chapters 9 and 14, and arguably some in parts of chapters 5, 11, and 13. By my count that's about 100 pages out of 490, or around 20%. Instead of 2/3 of the book being wrong-headed, it seems to me that the first 40% of it is an good solid introduction to the way OO Perl actually works; and that most of the rest of consists of useful, but non-essential, explanation too. Not bad for a book written a decade ago.

Personally, I'd rather have developers who have read Damian's OO book and therefore understand the underlying Perl OO mechanisms that Moose uses (or sometimes replaces), than have developers who don't understand how Perl OO actually works and just treat Moose as a magic wand.


Comment on Re^12: OO automatic accessor generation
Re^13: OO automatic accessor generation
by perigrin (Sexton) on Nov 17, 2009 at 23:42 UTC

    So by your count out of 14 chapters six document outdated or overly tricky features of the Perl OO model (5,8,9,10,11,14). while Five are straight forward useful (1,2,3,4,12) ... and one is useful but advanced (13).

    By my count that's 35% of the chapters that are directly useful to a Perl5 developer today. Those chapters are also front-loaded. Not bad for a flippant remark.

    As for encapsulation, I've listened to stvn's rant about it more than most people. The point isn't that encapsulation is bad, the point is that going out of your way to enforce encapsulation in a language like Perl is simply adding complexity with no benefit. Why double your code when a simple rolled up news paper across the nose is sufficient? "Bad Programmer, No Cookie!"

    That said I'd agree with you, I'd rather have a developer who read Damian's OO book for the 1/3 that is *useful* about OO Theory ... and then used Moose ... rather than a developer that doesn't understand OO at all and things Moose is a Magic Bullet. But given a raw programmer, I'd rather have them learn good OO theory using a proper tool like Moose than I would have to re-teach them all the things I had to forget when I moved from raw Perl OO to Moose three years ago.

      So by your count out of 14 chapters six document outdated or overly tricky features of the Perl OO model (5,8,9,10,11,14). while Five are straight forward useful (1,2,3,4,12) ... and one is useful but advanced (13).
      No. By my count, the vast majority of about ten chapters is still directly useful.
      By my count that's 35% of the chapters that are directly useful to a Perl5 developer today
      By my count, it's 70% still useful. Just because you don't choose to implement a design using Class::MethodMaker, doesn't make learning it useless. Likewise, encapsulation and multiple dispatch. I despair when people think that only the stuff they'll need today is useful. Knowing how others have done things in the past is valuable. Breadth of understanding is worthwhile, even if you never use the techniques shown yourself.

      I've heard Damian Conway call that "repertoire" and say how important it is to know a wide range of things, both fundamental and advanced, useful and "tricky". He says it's one of the things that makes a good programmer a great programmer, not just because you know five ways to solve a problem, but also because understanding five ways and their advantages and limitation helps you see why one particular way is better than the other four.

      Besides, basing that "flippant remark" on a chapter count (however you choose to count them) is utterly misleading. It assumes all chapters are equally long, which they're certainly not. Might as well say that 1 out of 1 "OO Perl" books contain invalid material, so the book's 100% invalid. Or that 207 of the 283 Moose:: modules have at least open bug report, so Moose is 73% buggy.

      In fairness, not all pages are equal either, so basing any evaluation of the book on page counts is misleading too. But at least there are enough pages for the differences to even out, so page counts get nearer the truth than basing an assessment on arbitrary divisions like chapters.

      The point isn't that encapsulation is bad, the point is that going out of your way to enforce encapsulation in a language like Perl is simply adding complexity with no benefit. Why double your code when a simple rolled up news paper across the nose is sufficient? "Bad Programmer, No Cookie!"
      There's no point arguing this. You could argue exactly the same about (for example) Moose bringing type checking to attribute assignments.

      Encapsulation does bring benefits, and can certainly be added to Perl without "doubling the code". Modern inside-out techniques are hardly any more onerous than vanilla hash-based objects, and modules like Object::InsideOut make simple encapsulated classes even less onerous to set up than using Moose.

      But given a raw programmer, I'd rather have them learn good OO theory using a proper tool like Moose than I would have to re-teach them all the things I had to forget when I moved from raw Perl OO to Moose three years ago.
      You know, it's always respected programmers like yourself who I see advising us beginners to avoid learning all the core stuff that made you excellent programmers excellent in the first place. Knowing how OO Perl actually works, you have the luxury of wishing you didn't, while still enjoying the many subtle benefits of that knowledge. It's almost like a conspiracy by the Perl elite to keep the masses in our proper state of limited understanding. ;-)

      Seriously though, understanding how things actually work is important, even when very useful coatings of module-based magic are layered over them. You can't really be great at a language if you don't understand how that language really works, no matter how well you understand any tool built on top of that language. Ultimately, all metaphors break down, and that's just as true of the programming metaphors we call libraries or modules. And, at that point, if you don't understand the mechanism the metaphor is simplifying, you're in deep trouble.

      I guess my point is that throw-away remarks that denigrate a dated but well-written book (which still contains, in my view, a lot more than just 1/3 useful information) don't really do justice to the book, to Moose, or to Perl. Or to the many beginners who want to benefit from understanding all three.

        By my count, it's 70% still useful. Just because you don't choose to implement a design using Class::MethodMaker, doesn't make learning it useless. Likewise, encapsulation and multiple dispatch. I despair when people think that only the stuff they'll need today is useful. Knowing how others have done things in the past is valuable. Breadth of understanding is worthwhile, even if you never use the techniques shown yourself.

        Well the point was that your definition wasn’t equivalent to stvn’s definition and was leading to a Straw Man argument. We’ve obviously loaded up the straw man because your definition of useful ignores my use of the word directly in this context.

        Happily we both agree that having a broad range of knowledge is useful. I know more now about a much larger range of topics because of Moose than I did before. I also think that there is a very large difference between knowing abstract theory, and practical application. I think that the arguments people have in this thread and on Perl Monks in general are because one side is saying “abstract theory!” and the other is saying “practical applications!”. Both are useful. I personally would prefer to help people learn by showing them practical applications that lead to a deeper understanding of theory, and I happen to think Moose is the best way to do that.

        Besides, basing that "flippant remark" on a chapter count (however you choose to count them) is utterly misleading. It assumes all chapters are equally long, which they're certainly not. Might as well say that 1 out of 1 "OO Perl" books contain invalid material, so the book's 100% invalid. Or that 207 of the 283 Moose:: modules have at least open bug report, so Moose is 73% buggy.

        His “flippant remark” was I think more accurate than yours though. Moose only has 108 modules in the Moose distribution, and that only has 14 bugs so Moose’s core distribution is only 13% buggy.

        The point isn't that encapsulation is bad, the point is that going out of your way to enforce encapsulation in a language like Perl is simply adding complexity with no benefit. Why double your code when a simple rolled up news paper across the nose is sufficient? "Bad Programmer, No Cookie!"
        There's no point arguing this. You could argue exactly the same about (for example) Moose bringing type checking to attribute assignments. Encapsulation does bring benefits, and can certainly be added to Perl without "doubling the code". Modern inside-out techniques are hardly any more onerous than vanilla hash-based objects, and modules like Object::InsideOut make simple encapsulated classes even less onerous to set up than using Moose.

        You’re right, there is no point arguing this. I was simply clarifying stvn’s position on Encapsulation. He’s not arguing against Encapsulation, he’s arguing against strong enforcement. He I believe feels that it’s not worth the effort in Perl. I happen to agree with him having implemented Inside Out objects in a project (shortly after reading Damian’s OO book infact) and ran into several serious issues dealing with them because they actively worked against the natural tools Perl has to deal with complex data structures. Happily opinions are like assholes and we can both have one.

        You know, it's always respected programmers like yourself who I see advising us beginners to avoid learning all the core stuff that made you excellent programmers excellent in the first place. Knowing how OO Perl actually works, you have the luxury of wishing you didn't, while still enjoying the many subtle benefits of that knowledge. It's almost like a conspiracy by the Perl elite to keep the masses in our proper state of limited understanding. ;-)

        Flattery is an excellent weapon. We’ll assume you’re right, I would argue that “respected programmers” simply trying to help beginners (and your arguments here seriously suggest you are anything but a “beginner”) to learn from our mistakes so that they can make wholly new and interesting mistakes of their own. If we all had to learn the same stupid crap over and over the world would never advance.

        There is time to learn how Perl implements OO, and in fact there is what I feel to be a good start in Moose documentation with Moose::Manual::Unsweetend. I however feel that time isn’t when you’re learning OO theory and practice, but when you’re ready to learn how a practical application (Moose, Class::MethodMaker, Object::InsideOut) is implemented and reflects that theory.

        I'm not being high and mighty here either. It seems irresponsible to say to a beginner that they have to suffer through all the difficult lessons I and others have learned. Especially when we've spent three years encapsulating most of those lessons inside Moose. Nobody is advocating not learning proper theory, we're just advocating you learn from the community.

        Seriously though, understanding how things actually work is important, even when very useful coatings of module-based magic are layered over them. You can't really be great at a language if you don't understand how that language really works, no matter how well you understand any tool built on top of that language. Ultimately, all metaphors break down, and that's just as true of the programming metaphors we call libraries or modules. And, at that point, if you don't understand the mechanism the metaphor is simplifying, you're in deep trouble. I guess my point is that throw-away remarks that denigrate a dated but well-written book (which still contains, in my view, a lot more than just 1/3 useful information) don't really do justice to the book, to Moose, or to Perl. Or to the many beginners who want to benefit from understanding all three.

        This is where we’re misunderstanding each other. If you’d been part of the Moose community for any of the conversations that come up with a beginner asks what a good book for learning OO theory is, Damian’s books is almost always recommended because as you and stvn both rightly point out the first four chapters (the first 1/3) is probably one of the single best introductions to OO out there. the other things that come up are the already mentioned Moose::Manual::Unsweetend, as well as Art of the Metaobject Protocol.

        We disagree on how useful the rest of Damian’s OO book are for learning OO theory and really understanding what is going on. Those chapters of Damian’s book are the ones that are aging the hardest as they don’t do a reasonable job of explaining things like an Attribute Metaobject Protocol (which is one of the most powerful concepts that makes Moose the workhorse it can be), but instead focus on esoterica inside the Perl universe at the time the book was written (and yes multimethods are an exception, but I didn’t really find the description there anymore compelling for an explanation than say MooseX::MultiMethods).

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://807057]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (8)
As of 2014-09-22 10:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (189 votes), past polls