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...
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.
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.
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.
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.
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.
But... the example was all there was. This wasn't an article with a core point that simply picked a bad example. There's almost no text. If the code exhibited isn't good enough to make the point, then what point is there to be made?
I understood the point only because I have practical experience working with large amounts of Perl 5 code in every stage of the mentioned enlightenment. The example worked for me; it won't work for people without that experience.
No, I also thought that the first example was the most clear, assuming you know how a hash table is typically used in Perl. One of the reasons I like Perl is you can frequently solve problems with the built in data structures, you don't have to get your head around someone's attempt to model out every bit with an object.
Sure, but that's trivially fixable with a few my's scattered around. It doesn't change the character of the solution, which is why I thought the complaints were mostly straw men. Sure, you can do dumb stuff in perl, and people might have written like that. But that by itself isn't an argument for "new style perl" (which specifically seems to mean Moose here). You can also write clean and clear perl in "90's style".
I think you taking the examples more literally than the author intended (NB. the authors mothers tongue isn't english).
Some of the points I believe the author is trying to get across:
* Always have "use strict;" (and declare variables scope)
* Make use of CPAN (eg. Term::Readline)
* Don't use indirect object syntax
* And use Moose if doing OO
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...