in reply to "Perl is the Cobol of the WWW"
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.
|
|---|