But what would you say to this person?

Me? Probably nothing. Those who've gone down the path of buying hype aren't likely to listen to reason. Now if the manager had said "sorry, we've evaluated Perl but PHP better fit our needs", I'd be more likely to agree with this person. Sometimes PHP is a better fit.

If you have reason to believe that he's simply chosen a technology without clearly defining his needs, you could forward him this essay I wrote recently. At first it seems to only be peripherally related, but at the bottom I address that point. However, as I said at first, once people start to believe hype, they're not likely to stop. In fact, arguing with them may make your case worse. If you already know PHP, why not use that language?

Grab a copy of a existing project written in Perl that comes as close as possible to the customers requirements. Preferably one that makes heavy use of as many CPAN modules as possible. Skin it to have your customers name and colours. Ie. Spend 1 day doing a shallow mock-up.

Then ask the customer to view this "quick mock-up written in Perl" to get his thoughts on layout, colors etc. Explain that you are just leveraging an old project to get something to talk about quickly.

Then explain that the first thing you are going to do is have to re-write modules X,Y,Z & P,Q,R & A, B, C in PHP so that you can avoid having to write all the back-end code from scratch. Try and get him to visit CPAN himself.

Fill an email with direct links to the modules that you would normally use for such a project in Perl, and ask him if he knows of any equivalent free modules in PHP, so that you can avoid re-inventing the wheel (at his expense).

If he says "Yes", he's saved you some time, but he might stop to think about his pocket book rather than buzz phrases.

He's paying you to do something? Just remember to add sufficient hours to your estimate to learn the language.

I think the tactful (and Spanish language) equivalent "it's your nickel" may be an appropriate, and safe, response.

The rather snarky "but isn't PHP the PL/1 of the WWW?" would probably a) go over his head and b) cause you to have need to look for other work.

I would ask him exactly what "having a future" means. In fact, every time I see someone write about how perl is dead or dying I really have no idea what they are talking about. Let's say all development on perl stopped today. Does that negate the usefulness of the tool? Will all of the binaries suddenly disappear? Will programs just stop working? No, no, and no. So even if there were no active development perl could still enjoy a relatively long afterlife.

Yet perl continues to have an active developer community. Does he think otherwise? Point him at the perl5-porters mailing list, and all of the activity surrounding perl6. Point him at the perl foundation and at the YAPCs and at the annual Perl conference. Point him at amazon.com and yahoo.com and the other major sites that continue to use perl. So, what constitutes "no future" exactly?

The only reasoning I can think of why people think PHP has a future and Perl doesn't is that Perl has implemented most (if not all) of the useful features extant while PHP still has yet to implement some language features. Ergo, PHP has a future (there's still stuff to be done) and perl doesn't (we've already done it all). :-)

Isn't yahoo.com done with PHP?

--
mowgli

Browse the wikipedia PHP entry. In particular look at the security issues posed by PHP.

Despite Perl is powerfull and eficient, it has become the Cobol of the WWW

I'd agree with him.

I'd consider it a compliment.

The application needs to be written in a language with a future

Depends on the estimated lifetime of the application. Perl 5 isn't going to disappear in the next few years. Well before it does we'll have much more information on whether PHP N>5, Ruby 2, Perl 6 or some other interesting language is going to get the most market share and/or be most useful.

(Personally I think Perl 6 vs Ruby 2 is going to be interesting.)

But what whould you say to this person?

If it were me I'd be advising him to pick whichever language gives him the most bang for his buck now. The way that PHP is evolving it's not going to be any easier to maintain than Perl 5 in a few years time - so I don't think he'll save anything long term. I just don't think we have enough information to make a good guess on what (if any) "dynamic" language is going to be dominant in five years time.

Update: Spooling mistook fixed. Thanks demerphq

COBOL had namespaces?

Yeah, one big one called "Working Storage" ;-)

In a few years there will still be a lot of Perl programmers around, but see if you can find someone who can still program in that particular version of PHP that was the hype when the page was written.

" All Unix / Linux installations come with Perl installed. "

Not true.

They don't? They should!

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

If people question you about the scalability of Perl, you might mention to them some of the companies that make extensive use of Perl: Amazon, Yahoo, Overture, TicketMaster, CitySearch, IMDB...

There are reasons that businesses moved away from Cobol. Those are not the same reasons that businesses are glomming onto the buzzword development environments. And the businesses that are focused on getting the job done are not moving away from Perl.

You mentioned 'charts', 'ruby' and 'ror' - have you seen http://nubyonrails.topfunky.com/articles/2005/07/28/sparklines-graph-library-for-ruby?

Cute! I was looking at the rubygem-that-calls-perl-that-calls-GD module, and that's when I sighed and went back to Perl.

While more and more functions will be implemented in Ruby, it does have a ways to go. Time will tell.

Take what he said in this way: Perl has been around for long time with WWW application, just like COBOL in some other areas. However this does not mean that Perl will fade away any time soon like COBOL did.

As for the project, if he is the person to decide the language, just let him decide. Most likely not much you can do.

Just recently I talked to someone who was not only maintaining COBOL programs, but actually still writing new ones.. So, "faded away" ? (And I know of at least one other company that uses it)

C.

However this does not mean that Perl will fade away any time soon like COBOL did.

Fade away? Surely some mistake :-) You'll be amazed at the amount of COBOL out there at the moment, and the amount of new COBOL that's still being written.

We should hope that Perl will still be used as much as COBOL is more than forty years after it was created.

My company still uses COBOL and we are constantly writing new programs and improving older ones. COBOL is a language that has been around for a long time, and I don't quite see it falling dead by the side of the road yet.


TStanley
--------
The only thing necessary for the triumph of evil is for good men to do nothing -- Edmund Burke

Seriously though, it depends on what you want to achieve. It doesn't sound like he wants to be persuaded, so either take the job (and bill for learning/converting things to PHP), or don't. The customer is always right, even when they're wrong. After all, if you're just doing a contract job, they have to maintain it, or find people to, so it's their problem.

C.

There seems to be a common misconception that all new technology must replace exisiting technology. In many applications twisted pair wires make more sense than fiber optics and the old technology lives next to the new technology. Radio didn't kill print. Television didn't kill radio.

We see this in economics. Many people are convinced that wealth creation means more poor people. But modern economies are not zero sum systems. Wealth creation creates a larger pie from which many enjoy larger portions than before. New software languages are often similar.

PHP didn't come in and replace applications. Like may other technologies had done before, it widened the use of programming as a solution to web site authors. Many people used PHP where they would have once stuck with HTML. The programming solutions pie got bigger. Everyone benefitted.

The customer is always right. If its PHP he wants and you are good at writing PHP programs, give him what he wants. Explain the limitations of PHP, but don't fall in love with Perl if it leads you to the poor house. It is okay to tell him he's wrong about Perl, just be careful not to maneuver him into a situation where you can say "I told you so." Perhaps you could introduce a PHP/Perl solution. Using each language where it is strongest.

That's quite dangerous.
<scene> You cannot do it in PHP? We'll find someone who can... </scene>


holli, /regexed monk/

"OK, here's my card, call me when you find that the PHP version is getting too expensive"

"Despite Perl is powerfull and eficient, it has become the Cobol of the WWW"

Two out of three ain't bad!"

"Despite Perl is powerful and eficient, it has become the Cobol of the WWW".

It seems to me he might really be confusing CGI with Perl. Many people associate the two. CGI, of course, has a limited usefulness. Maybe he doesn't know about mod_perl?

-sauoq
"My two cents aren't worth a dime.";

I've used both for developing websites, though I'm no expert at either.

I started with Perl in around 2001 and I'm still using it for web stuff. I explored recently with using PHP.

I find that my experience with PHP is rather like my experience with Perl at the beginning, when I tended to freely mix code and html. I only know PHP superficially, so maybe that's why I haven't found a more elegant way to separate the logic from the presentation.

For small sites (a couple of static pages with limited interactive features), I would go with PHP. PHP is rather like Javascript, so it makes adding logic to the html page much easier.

For a larger web project, Perl will still be my choice of programming language. I find that I'm more organised when coding in Perl. Besides, I'm familiar with using a number of very useful modules such as EncryptForm, DBI and HTML::Template, so it makes sense to tap on that knowledge.

If it's a simple PHP job and you need the money fine but if it's a big project with little money I would say quit. I've done it and hated every step wishing I had perl. The customer specified PHP mainly because they wanted to be sure subpar engineers could edit the simple-looking PHP files. To be specific, the customer was a former coworker and project manager who cannot read perl and he wanted to be able to edit it. I am willing to bet that you are in the exact same situation. No sane client otherwise will say PHP is a language with a future.

That depends a lot on my relationship with the customer. Generally, I am being hired directly as a contractor, and so I'm a bit more direct than I would recommend if you are an employee somewhere along the line. I also don't know the background of this.

Confronted with this situation in the past, I responded this way:

I'd be more than happy to develop this in PHP for you. However, you should be aware of a few things before you finalize your decision. First, since PHP does not provide the comprehensive CPAN library, this solution will take more time to create: my quoted price will increase. Second, since PHP does not provide adequate unit-testing facilities, I will require a signed limitation of liability from you which indicates that you understand the risk; additionally, I cannot offer you flat-rate support for PHP, it is hourly only. Third, given PHP's security record and the lack of adequate testing I mentioned above, I am unable to offer you my standard warranty.

I will be happy to meet with you to discuss the details of why I must take these precautions with PHP and not with Perl, and perhaps I can address your concerns about choosing Perl for your project. Also, I would be pleased to work with you to select an alternative language if neither PHP nor Perl are appropriate for you.

I had one customer choose not to work with me ("Your PHP requirements are unreasonable." he said. His project went 250% over budget. :P). The others I've taken this approach with have typically met with me to discuss the issues. They all came away with a much higher level of comfort about Perl, even though many of them chose to take a different approach.

Ultimately, if you feel that PHP is a risk to the project, you need to go on record as saying so -- if you must use PHP despite your objections, be sure to make it the best you can, but document the problems thoroughly.

But what whould you say to this person?

But that's just me. I'm senior enough and around long enough that I can say that to most of the managers I've had the last decade or so.

Don't take it as a blanket recommendation to tell it to your manager.

Of course, a manager can have non- technical issues to favour PHP over Perl. And he will have the last say in it. But I'm hired for my technical expertise - and I will voice my opinions and objections. That's part of my job. (I don't think singing I told you so is part of the job, but I've done so in the past).

News Factor - New Technology for Business and Pleasure. Perl mentioned often!