I work for a contracting company that does the websites for a sizable company with lots of seperate brands. Our code, while needing to be cleaned up in many respects, is definately not Perl3-quality. If someone tells me that Perl isn't scalable, I laugh in their face. I live scalable Perl code every day.

My grandfather was in IT management for a long time, and was once the head of IT for Rayovac. He was surprised that we could manage such a large collection of brands with the handful of developers we have. I'm not.

The problem though, is that Perl is highly susceptable to Sturgeon's Law. If you're going to use Perl, you need to hire out of only the top 10% of coders, because the rest will write code that becomes a disaster in the long run. Fortunately, following Brook's musings of the Mythical Man-Month, those top 10% will be 5-10 better than the rest (while also happy with salaries that are only 1.5-2 times more).

I think you'll get two basic forms of response. One will be "Huh? What do you mean, by 'dirty'? Oh, can you help me with my code? <insert perl4 code here>" The other will be "I've been saying that for years." ;-)

I suppose the main problem I would have with Ovid's comments is that he is really preaching to the choir here. There's not one iota that I would disagree with - it's just getting to those perl3/4 programmers that he wants to change ... they aren't likely to be reading perl.com (or perlmonks). Which is unfortunate. Perhaps the same article geared towards talking to those PHP, Python, C, Java programmers that denigrate the "write-only" perl3/4 style code as an explanation of historical interest would be of slightly more use as a link for when those discussions come up. Say you're getting flamed for your perliness in an IRC channel - being able to point to Ovid's wonderful essay on the question may provide some talking points which could cool a heated conversation. Sure, it may not get them to start writing perl, but can give proper balance to their thoughts on the language, helping to differentiate the language from (some of) its users.

It may look like I'm preaching to the choir, but I actually posted that to my O'Reilly blog. That has a much wider audience.

Cheers,
Ovid

New address of my CGI Course.

If that is something you are interested in, you may take notice of a previous meditation on a very similar subject. I disagreed with that one, too.

As a counterpoint was a recent challenge of mine. Though spiritway basically said the same as you, davido's response was bang on: there is much to be learned when exploring corner cases.

The thing to always remember is that, while there are some really truly bad ways to do some things (see the above thread for some hideous examples ;-}), you need to know lots of ways to do something because what you did last time as part of a simple application may not apply in a CGI environment, or a client-server environment. With encryption. Or tainting. A key point of TIMTOWTDI is that there is also more than one scenario in which you may want to do it. And thus the "superior" answer for last time may be second-rate in the new environment. Luckily, knowing so many ways to do something means I can adapt something a bit different for this one.

PS: You should always use The Right Way for your scenario. I'm just saying that you should know many ways so you can evaluate them and pick the real right one, not the right one for a different scenario.

There is more than one way, and there can be more than one right way. Notice I said, 'can'. I have spent some time lately reading and re-reading portions of thedamian's "Perl Best Practices". I don't always agree 100% with what he has to say, but he argues it well and gives good sound reasons for adpoting the practice he prescribes. Some years back I took much advice from merlyn and Joseph Hall in "Effective Perl Programming" for the same reasons.

The biggest problem I see is that the arguments against Perl are often made by fad followers who have never used the language! And then the perpetrators of some truly horrible code are pronounced heroes by a seemingly ignorant few.

In my estimation, one of Perl's biggest problems is also its greatest strength. It is readilly available and approachable by most people with only slightly more than a passing interest in programming. Thus resulting in a series of public archives and references that are a great ego boost to the authors, but a mill-stone arund the neck of many others in the community.

jdtoronto

Proposal: The Right Ways To Do It.

One right way will lead to one way, one way will lead to *THE* way. and *THE* way is not always right.

---

Ordinary morality is for ordinary people. -- Aleister Crowley

However it's something we need to keep reminding ourselves. FORMMAIL - Despite massive security issues and even a complete re-write it seems that many people, even commercial services, are still using the original mess. SO how do we over-come this sort of stupidity? And then about.com wont update their information even when people advise them of issues.

jdtoronto

Ovid's solution: Use more CPAN. He says "Most of the tools you need to build most common applications have already been written and are waiting for you on the CPAN."

There are a couple of problems with this solution, IMO. Some of the modules in CPAN aren't that great (some, like, Text::Netstr are just horribly broken) and there's no obvious way to seperate the good from the bad, or even say "please don't use this it's broken".

Also perl tends to make hacks really easy, couple that with the fact that adding dependencies is generally painful and it's often easier to ignore/not-think-about the corner cases and just paste some simple code in.

One solution might be to make installing from CPAN much easier (for a packaged distro, say), but people have been saying that for a long time ... and perl-DateManip is in basically every distro. and I still see code avoiding it.

perl-DateManip is in basically every distro. and I still see code avoiding it.

That's because it's horrible. Even the author doesn't recommend that you use it:

Is Date::Manip the one you should be using? In my opinion, the answer is no most of the time. (Should I Use Date::Manip?)

Please get into the habit of recommending DateTime.pm and its friends. That's the best way to handle dates and times in Perl.

--
<http://dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

From the same page:

On the other hand, if you want one solution for all your date needs, don't need peak speed, or are trying to do more exotic date operations, Date::Manip is for you. Operations on things like business dates, foreign language dates, holidays and other recurring events, etc. are available more-or-less exclusively in Date::Manip.

This is the reason I recommend it, the speed is rarely a factor (for what I do, YMMV). The API that I use in 99% of cases is 2-3 functions.

Also AFAICS if you have a "Date and time" as a string there is no DateTime constructor to pass it to Date::Manip::ParseDate "just works". Getting a readable version of the data out also seems much harder than calling Date::Manip::UnixDate too.

But all of this just proves my other point, if you want an answer to the question "Which module should I use to do X" you can't easily get an answer ... you have to either pick a module and hope, or hack some code in directly that you know/think solves your problem.

--
And-httpd, $2,000 security guarantee
James Antill

One solution might be to make installing from CPAN much easier (for a packaged distro, say), but people have been saying that for a long time ... and perl-DateManip is in basically every distro. and I still see code avoiding it.

Hmm... I can't find it on my system. I've got perl5.6.1; maybe that's too old?

Has the perl community finally standardized on a single, reliable date and time module? Every place I've ever worked, there's always been some home-grown date/time solution, and when I suggested downloading something from CPAN, no one could decide on what to download, so they had an excuse to maintain the status quo. *sigh*

If perl5.8 has a standard date/time module, that's reason to upgrade right there, IMHO. Is Date::Manip it, or was that just your favourite choice in yet another CPAN holy war?

Date::Manip is ancient and was highly regarded for being very flexible (especially at parsing date strings of unknown format) but noted for being quite "slow". It certainly isn't a "new date/time module" that people are trying to standardize on.

I still see quite a few different date/time modules being suggested so consolidation is not working very well yet from my perspective. I recall that there is work being done on some Holy Grail suite of Perl date/time modules but don't recall the namespace (it was something really simple like DateTime::*), which might say something about why consolidation isn't finished. I certainly don't have a good idea where I'd go to figure out which date/time module currently has the most support and that is part of why I don't use any date/time modules.

I just use localtime, gmtime, and Time::Local and sometimes POSIX::strftime() and would find learning some module time-consuming and fully expect to find using the module to be quite frustrating. But I'm sure most peoples' mileage will vary.

- tye        

DateTime is the best date time module. Comprehensive but nice object-oriented interface over quick-and-dirty. Handles timezones. Heck, it handles tons of different formats and even other calendars. There is a lot of modules to install from CPAN but you will be happy once you get them installed.