Seriously though, it could be argued that sending people to learn the old, tedious way of Perl OOP first will drive some new users away. Especially with languages like Ruby and Python out there which have nice OO out of the box. Don't get me wrong, I totally think that you should learn your roots, but Perl OOP not only imposes a lot more work but can teach really wrong headed behavior (due largely to its extreme minimalism), 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.

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.

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.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other