Re: Where i can use Perl?

Hi Lorn,

"Perl is used in lots of places" isn't really a convincing argument. So is Java, Python, C, Ruby, PHP, and a host of other languages. One could get away with writing crawlers in Lisp, if one really wanted to (in fact, I think Amazon did for a while in the 90s). That's not the road you want to take in this.

A better approach is to find out why they want to rewrite the software, and address those reasons, one by one.

You have two major advantages already -- you have the software, and the software works!

I'll attempt to list a few of the more common reasons management decides to embark on this sort of thing, and how to address each argument.

Perl is hard to maintain -- is it? Do you have a log of the crawler development -- bug fixes, feature additions, release history? Did multiple developers touch it? Do you have any statistics on how long it took to find and fix bugs?
Everything else is in PHP -- great, and I bet it works. This also works. Isn't there software that doesn't work we could be fixing, or software that doesn't exist we could be writing? The existing stuff already does the job. Why waste time and money, if the end functionality will be the same?
PHP can do X -- so can Perl. Perl can do more.
Perl is slow -- first, get statistics on your software. Does the code really run slowly, or is this just a management's preconception? See if there is anything you can get as a quick speed improvement, if they bring this up (as a bonus, this punches the "hard to maintain" argument right in the gut).
We want to use a PHP framework and common libraries -- that's actually a good reason. If they already have that kind of stuff, it totally makes sense to port the code so everyone can work from the same page and not have to write the same functions twice in different languages.
We have little Perl expertise -- update your resume. If you are the perl guy, and they say something like that, your prospects at this company are bleak.

I've gone through this many times at a few places (let's rewrite this in X, X is nicer) -- and every time the winning argument is turning management-speak back on them -- what is the ROI of this effort?

Works on managers who are big fans of buying instead of building, too. "It'll cost you 2 weeks of my time to add this to the current system. It'll cost you 6 months to configure this newly bought software just to do what this stuff already does. Do you really want to do that?"

Good luck!

Comment on Re: Where i can use Perl?

Replies are listed 'Best First'.
Re^2: Where i can use Perl? by strfry() (Monk) on Apr 17, 2008 at 02:10 UTC
We want to use a PHP framework and common libraries -- that's actually a good reason. If they already have that kind of stuff, it totally makes sense to port the code so everyone can work from the same page and not have to write the same functions twice in different languages. Regarding ROI, it might be easier and less time consuming to take what they have and massage it to work with an already existing Perl framework (CGI::Application, or Catalyst, for example), than port everything over to PHP just to be able to use their goodies. This is especially true if the existing Perl code is well written. Also, the size of the Perl code base would come into play as well. He'd do well to research CPAN modules that PHP doesn't have an equivalent of, since if they want the same functionality, they'll have to be rewritten as well. Obviously, without knowing the amount of code already written in PHP vs that written in Perl, it's tough to give an informed opinion. I mean, if it's just this spider written in Perl, and hundreds of apps in PHP, oh yeah, hop on that PHP framework. Symfony is a nice one, I hear. (: But if it's just because "we heard that PHP is great!" then this might be symptomatic of larger issues with the company, and like you said, he might want to brush up his resume a bit. Just my $0.02.	[reply]

Replies are listed 'Best First'.

Re^2: Where i can use Perl?
by strfry() (Monk) on Apr 17, 2008 at 02:10 UTC

We want to use a PHP framework and common libraries -- that's actually a good reason. If they already have that kind of stuff, it totally makes sense to port the code so everyone can work from the same page and not have to write the same functions twice in different languages.

Regarding ROI, it might be easier and less time consuming to take what they have and massage it to work with an already existing Perl framework (CGI::Application, or Catalyst, for example), than port everything over to PHP just to be able to use their goodies. This is especially true if the existing Perl code is well written. Also, the size of the Perl code base would come into play as well. He'd do well to research CPAN modules that PHP doesn't have an equivalent of, since if they want the same functionality, they'll have to be rewritten as well.

Obviously, without knowing the amount of code already written in PHP vs that written in Perl, it's tough to give an informed opinion. I mean, if it's just this spider written in Perl, and hundreds of apps in PHP, oh yeah, hop on that PHP framework. Symfony is a nice one, I hear. (:

But if it's just because "we heard that PHP is great!" then this might be symptomatic of larger issues with the company, and like you said, he might want to brush up his resume a bit.

Just my $0.02.

[reply]