OOP can be "baby" or "bad" in the same way that structured programming can be.
Hence the qualification, even when it would be
a good way to solve the problem at hand. Some
problems do naturally lend themselves to OO, although
of course most don't. It's not something you need
to learn in your first couple of years of programming
in Perl, but eventually you pick it up and add it
to your tool belt.
[short, simple sentences] might just as well be a hallmark of good Perl.
Are you seriously arguing that the example I gave of
what I was talking about constitutes good code, or
are you just trolling?
Regarding simplistic comments:
Maybe "baby" is the reason but "bad" is the result.
I guess that depends on who's most likely to need
the comments, the baby programmer himself, or
someone else. Bear in mind, for someone new to
a language, comments that remind what even a
simple, built-in feature does can be useful.
A more experienced programmer just *knows*,
of course, and you wouldn't want to see such
comments in important code -- but important
code should be maintained by experienced programmers
in any case. I don't think it's bad, when learning
a language, to use comments as a reminder to oneself
of language features. I do think you want to grow
out of that as you gain more knowledge of the
language, of course.