

Programming Style Evolution in Perl - jrey
http://perliscope.blogspot.com/2010/01/programming-style-evolution-in-perl.html

======
ajross
Am I the only one who (1) doesn't see much wrong with the early examples other
than weird/dumb whitespace and the lack of a comment explaining %tree, and (2)
thinks that the latter examples really don't bring much to the table? I guess
the Moose stuff is supposed to make it all clearer, but I just don't see it.

The complaints about the early examples are mostly straw men about variable
naming and whitespace. The (comparatively) _hard_ part here is the
understanding of how the data structure works, and that's something you could
stick in a 6-7 line comment...

~~~
dstorrs
Nope. I'm right with you on this. Personally, I would go farther--I would say
that Moose stuff is actually value negative.

For a simple thing like this, it makes perfect sense to use a simple
procedural style and keep it in one file. The Moose version just complicates
it beyond necessity. That's true of plenty of real-world programs, too.

~~~
jrockway
_The Moose version just complicates it beyond necessity. That's true of plenty
of real-world programs, too._

Learn what object-oriented programming is, then come back and tell us what you
think.

~~~
chromatic
For the example given? Nonsense.

It's very difficult to choose good examples for programming tutorials. In this
case, the example was too small and self-contained to support modern Perl
practices intended to help manage programs of hundreds of lines or more.

~~~
jrockway
Dunno, I use Moose for my small scripts and find them to be significantly more
maintainable than they would be if they were a bunch of code in a file. Hence
MooseX::Runnable.

"Procedural programming" is a generally meaningless term (even less meaningful
than "object-oriented programming"), but I find opportunities for abstraction
even in small programs. The procedural makes it difficult to exploit these
opportunities.

~~~
ajross
Again, that's kind of a straw man. All scripts are "just a bunch of code in a
file". You're equating your organization using Moose to the _inability_ to
organize code without it, which is silly.

You're also equating "abstration" with "good", which it isn't. You abstract
for practical reasons, not for its own sake.

~~~
jrockway
The abstraction makes it easy to reuse parts of your "one-off" scripts. For
example, look at the number of CPAN modules/programs that implement some sort
"restart when file is changed" functionality. There are a lot.

If you use MooseX::Runnable, though, you write an introspectable class instead
of a script. Now a plugin can handle adding this functionality to your script
in a structured way, and all you, the developer, have to do is say "mx-run
+Restart::Auto My::Class" instead of implementing that functionality manually
in your script.

Reuse is always good. Not writing code is even better.

