Re^3: What Perl CAN'T do?

90% of every Perl application you, personally, will ever really want to write is either already on CPAN or will be in the next year.

This is true, but only because I rarely find myself writing Perl applications because I really want to write them. Were it not for that caveat, that hasn't been true in any of my years of writing Perl, and I doubt that it will be true this year, either.

Perhaps I am just unlucky, or don't know where to look on CPAN for what I need, but I doubt that's it. Instead I think that it is because I wind up writing a lot of programs that are very specific to my local environment, and are solving problems that nobody else is interested in. Which is why I get paid, because I am doing stuff that I wouldn't do if I wasn't getting paid, and nobody else would do either.

For instance no matter how long I wait, I doubt that anyone will put on CPAN any of the reports that I need to write next week, all of which are very company specific.

Also I would like to point out that the 10 to 1 productivity differences with Perl are relative to very low-level languages, like C. Even a language like Java closes a significant fraction of that gap. Plus I don't believe that Perl is significantly more productive than, say, Python or Ruby. (In fact I believe that Ruby is actually more productive than Perl!) However I'll also admit that it is hard to find many real-world examples of really long programs written in highly productive languages.

Comment on Re^3: What Perl CAN'T do?

Replies are listed 'Best First'.
Re^4: What Perl CAN'T do? by dragonchild (Archbishop) on Dec 15, 2005 at 23:19 UTC
For instance no matter how long I wait, I doubt that anyone will put on CPAN any of the reports that I need to write next week, all of which are very company specific. While the specific items you need will never be on CPAN (because they're specific), you can definitely find a lot of glue code. When I write reporting apps, I reuse the following: Application framework Database access Creating output formats (HTML, XLS, PDF, CSV, XML, etc) Parsing input formats (xSV, XLS, PDF, XML, etc) So, maybe the actual report doesn't reuse anything from CPAN, but everything around it does. Also I would like to point out that the 10 to 1 productivity differences with Perl are relative to very low-level languages, like C. Even a language like Java closes a significant fraction of that gap. Plus I don't believe that Perl is significantly more productive than, say, Python or Ruby. (In fact I believe that Ruby is actually more productive than Perl!) However I'll also admit that it is hard to find many real-world examples of really long programs written in highly productive languages. I agree with you, but Perl is definitely very productive. And, frankly, I'm trying to shift our main development to Ruby, so I agree with you on that, too. :-) My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^5: What Perl CAN'T do? by tilly (Archbishop) on Dec 16, 2005 at 00:14 UTC
Each individual report reuses the framework, yes. But I have more reports than framework. Plus the framework that I use is somewhat tied to the specifics of the local system. A random reporting tip. If you have problems with browser reports timing out, add a feature that any report that takes above a certain amount of time gets mailed to the current user. It is a simple change to make, but you will become an instant hero.	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks