Re: "Baby" Perl versus "Bad" Perl

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.

Comment on Re: "Baby" Perl versus "Bad" Perl

Replies are listed 'Best First'.

Re^2: "Baby" Perl versus "Bad" Perl
by sauoq (Abbot) on Dec 05, 2005 at 20:42 UTC

Hence the qualification, even when it would be a good way to solve the problem at hand.

Your qualification doesn't address the issue at all. You seem to think that structured programming automatically must come prior to OOP in some way. That's not the case even if it is the order you learned those paradigms. As evidence of this, I could point you at any of dozens (more likely hundreds or thousands) of degree programs in computer science that have opted to use C++ or Java as their teaching languages.

A choice to use a procedural approach when an OO approach would do nicely doesn't mark code as either "baby" or "bad" any more than, say, choosing to use an OO approach when a functional approach would be a good way to solve the problem at hand.

And, despite your assertion to the contrary, I know several very competent Perl programmers who have been programming in Perl for a decade or more and never use Perl's OO features (except when forced to by Some::Module's interface.)

Are you seriously arguing that the example I gave of what I was talking about constitutes good code, or are you just trolling?

Firstly, there is nothing particularly bad about the example code you gave. If it was really solving a problem, I'd be perfectly content to see it written that way. Secondly, your example was highly contrived and looked more like an example you'd find in a programming tutorial than "real" code. Sure... programming exercises are "baby"... but, that's by design. I think we were discussing real-life code.

Lastly, are you seriously suggesting in any way whatsoever that I might be trolling? Well, you get a decrement from me for that and I suspect that's the comment that earned you the (currently) one other decrement on this node.

Edit: minor grammatical correction.

-sauoq
"My two cents aren't worth a dime.";

[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks