Cross-posted from dream.in.code:

That's a big question which goes straight to the heart of Perl and plays a big role in why Perl is such a love-it-or-hate-it language.

This week is something of a gimme for me, given that I've already done app development against the Twitter API. For the sake of something simple and accessible, I opted to revise my earlier Iron Man post on Monitoring Hashtags with Perl and Net::Twitter to make use of Twitter::TagGrep and call that my DIC 52 Weeks of Code entry for this week:

Call it loose coupling, application of encapsulation, avoiding god objects, plugin-based architecture, or whatever else, but I don't like having objects which carry out the functions of another class's objects. I believe that each class should contain the full measure of its functionality, so that adding it to a project is as simple as use MyClass; without requiring modification of any existing code for the new class to do its thing. (Existing code will often need to be modified to tell it to use the new class, of course, but that's not what I'm talking about here.)

Unfortunately, KiokuDB::Tutorial's example of using Search::GIN hardcodes knowledge of how the Person class should be indexed into the database ->connect call. I'm sure this was just done for the sake of showing the simplest possible example, but here's how I set things up so that my ->connects don't have to change when a new class or index is added.

My second trip to #kiokudb came about when I got to the point of wanting to edit my objects through a web interface, which called for identifying the object I was editing. While Kioku was assigning unique IDs to each object which would be perfect for the purpose, the objects themselves didn't have access to their IDs and so couldn't provide them to my templates for insertion in the pages. Starting from my root node and walking the object graph every time seemed unreasonable and

$dir->store($obj);
$obj->id($dir->object_to_id($conf));
$dir->store($obj);

As mentioned in my last post here, I've recently started in on a free-time project to teach myself some of the more-currently-popular modules that I haven't been using. So far, that means Moose and KiokuDB. Moose has been coming along pretty readily so far (I'm not entirely sure whether that's because of MooseX::Declare or in spite of it), but KiokuDB has had me scratching my head quite a bit and sent me off to IRC twice for help.

So it's back to Perl Iron Man after *mumble* months. And back to square one in Perl Iron Man, thanks to those months, but that's no real surprise - I've always been a lousy blogger because I never seem to be able to find topics to write about on anything resembling a regular basis.

I do have another excuse aside from lack of topics, though: I was too busy writing Perl to bother with taking the time to write about Perl.

Marc Mims has recently taken over maintainership of Net::Twitter and rebuilt it on top of Moose. This has been a cause of much concern for me, as it does not appear that the non-Moose Net::Twitter::Lite will meet my needs. Yesterday's Net::Twitter Roadmap post proved quite reassuring in that regard, but did not fully address my concerns. As Marc's blog does not appear to support comments, I am posting my thoughts on it here.

In the last couple weeks, I've seen Perl questions on at least two separate forums which revolved around the connection between .pm files and Perl packages. Really, though, this connection is quite easy to understand if you just remember one thing:

It doesn't exist.

Noting my post on how the web was lost, Sam Crawley has asked "Can Perl ever regain its reputation?", ending with:

Yes, it does matter, not only for emotional and stubborn reasons, but also for rational and pragmatic ones.

There was a time when Perl, operating through CGI, ruled the web as king of dynamic sites. Things have changed quite a bit since then. Perl has grown to become a much stronger language, but it has also fallen from favor and lingers in the broader software development community's eye primarily as a whipping boy to be brought out only as a source of horror.

How did this happen?

We do have a legacy of poorly-structured, obfuscated, insecure Perl 4 code to overcome, which doesn't help matters any. This is being addressed by the "Modern Perl" and "Enlightened Perl" camps, including the Enlightened Perl Iron Man Challenge which I am participating in, and their efforts to show that it's not only possible, but easy to write well-structured, maintainable, elegant code in Perl 5. CPAN provides us a wealth of development frameworks, reusable objects, and everything else that today's developers expect to find in a language, and Modern/Enlightened Perl encourage heavy use of them.