Bottom line, take the job that pays best and learn PHP - you're not selling out, Perl isn't necessarily the best solution to everything - but steer the company towards Perl for any admin or data processing work. Perl offers the most gain when its strengths are catered to. I never use PHP for anything complicated, it's just that many things aren't complicated.

I doubt you're going to find a company already using PHP that will let you switch them entirely to Perl, unless you happen to be their only programmer and can show that you produce working solutions many times faster in Perl.

On the other hand, PHP can be inserted inside your page

Which is precisely why we don't use PHP, ASP, or CF. As a graphic design firm, we need to keep the executable code as far from the presentation and structual code as possible, other our designers (who are not programmers) get confused between the two.

The other thing that we are not crazy about is that PHP seems to have a function for everything where Perl leaves a bit more to the imagination. But the long and the short of it is that it's what you get used to.


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

Love Perl is being romantic, but use Perl for everything is being stupid.

I've so far been able to convert any piece of PHP to Perl (haven't encountered Smarty yet, would be an interesting challenge), but the opposite is painful. I still want to be able to do automated conversions of PHP code to Perl code, but it's hard to emulate PHP's broken arrays, and writing numerous functions --with bug-for-bug compatibility-- sucks too.

PHP can be made fast nowadays, so performance is no longer a good argument against it. But it STILL, after so many years, cannot handle sufficient complexity or scale. But even if it could handle large scale programs in a nice way, I'd still not use it, because lack of anonymous functions, lack of lexical variables, lack of strict declaration mode, lack of real arrays, etc, keep me from being productive. I constantly have to search for alternatives to things that real programmers take for granted, and trying to make sense out of PHP's beginner-oriented documentation takes time.

mod_php is faster at serving static content than mod_perl is ;)

Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

I'll have to take your word for it, but since we are nitpicking i'd like to point out that we use non mod_XXXX enabled Apache servers to serve most of our static content here where i work. ;)

UPDATE: We have Apache2 servers on the front end and mod_perl enabled servers on the back end. It works great for us. :)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Being marginally faster is no longer a big deal any more. There are too many more important things to worry about with a project today.

As I always say on IRC and occasionally here, TMTOWTDI includes ways that don't involve perl. Use what works. If the company line is towed by PHP but it's an otherwise decent job, learn PHP. If you feel dirty using PHP, spend some time trying to convert parts of the application to perl or use perl in other places to make hard tasks easier. Et cetera.

How about the fact that PHP began life as a Perl templating module (a la Embperl or Template Toolkit) that got out of hand? To me, that's quite the "'Nuff said!".

I'm not sure I get it. What is said by it? I can argue both ways.

Perl's purpose has also changed much over time. It's still a very strong string manipulator, but fares well in other areas too.

Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

Whenever I work in PHP, it feels like I'm working in an odd version of TT, except that
• I can't dip back into Perl if I want to
• I don't control the variables available to me
• I have to do all my work in my templates

PHP began life as a Perl templating module and hasn't outgrown its roots. As of Perl5, neither had Perl. Perl6 will be the first time Perl will have outgrown its roots and truly blossomed as a programming language. That Perl could do as much speaks to the roots TimToady gave it.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Yo Withigo:

Since we know each other I thought I'd write down a few of my thoughts evoked by your question. I've been on both sides of the PHP-Perl fence when it comes to web development and I think I have a fairly good grasp of the concerns of both camps. I realize we don't really see eye-to-eye on a lot of issues so feel free to ignore me if you so desire.

There are a lot of technical facts we can flaunt and discuss until the dogs came home. In the end there will only be one thing that really matters: either you'll have a job or you won't.

When I started building XpanceNET I built it using PHP. With the exception of some issues with stack size pretty much everything I wrote was cross-platform out of the box (more so than a lot of complicated Perl applications I would think -- especially those that use a many CPAN modules). I didn't have to go thinking about details that distracted me from the web application and for all intended purposes I think the outcome was fairly good. In hind sight we (the company) didn't spend enough time considering our problem domain and a year later we were stuck in deep mud with our application. Perl came along when I realized that XpanceNET was much more than a simple web application and that we needed to branch out into long running processes, something that even now is particularly difficult to accomplish with PHP.

I think that the old adage of "picking the right tool for the job" applies well in this sort of situation. I have since moved on from Morcor to a new company and I have to say I've never been more satisfied with an employer such as I am now. I work from home now alongside other developers spread out over North America. We have an office that I've never been to and I work alongside professional and trustworthy individuals who are all very good at what they do. My manager is focused and manages our time well. And yes, we use PHP almost entirely.

I don't have any illusions about "converting" our development team to Perl or even convincing them to switch. It would be a terrible idea to rewrite our applications in Perl; talk about wasted time and energy. Perhaps Perl has a future in some new project or application? I think there are some possibilities there. Don't sell yourself short just because you happen to use PHP; there are many successful companies and effective developers that have chosen PHP as their language for web applications.

I still use Perl for personal projects and small utilities that I build to make myself more productive but it is no longer a language I use to earn my keep with. At least, not for the immediate future. Professional software developers must feel comfortable developing without their language of choice. I found this article to have a interesting (albeit humourous and stereotypical) description of some programmers who were particularly aligned with their language of choice.

Do I miss Perl? Sometimes. Until I remind myself that in the end it doesn't matter what language you code in: specialization is for insects.

As for being faster to code, it's faster for small things to work from one file and insert a few lines of code, than it is to work with a templating system and keep the code and HTML separate. Of course, some people may want to keep them separate just on general principle - or if the people managing the content get confused when you mix in code - and in those cases Perl is definitely the better solution. But again, not if all you have available is CGI.

Perrin: I've read that PHP is comparable in speed to mod_perl, but if all you have available is CGI (as is the case on most remote hosting accounts?), then PHP is going to run significantly faster. Unless I'm missing something obvious here.

What you read is wrong.

CGI is not Perl, but a protocol that allows a webserver to communicate with specially designed programs. These programs can be written in any language, including both Perl and PHP. The only requirement is that the CGI program is executable.

CGI is slow, so both Perl and PHP offer an integrated solution, that runs within Apache. These solutions are called mod_perl and mod_php respectively.

In general --though exceptions exist-- mod_perl is faster than mod_perl, and CGI+Perl is faster than CGI+PHP. It's incredibly silly to compare speeds of mod_php versus CGI, as the integrated solution will win from the heavy communications protocol that involves forking off a new process for each pageview.

It's true, that if all you have are mod_php and CGI, the mod_php solution will probably run faster. But this is only relevant if you're tied to cheap bulk hosting. Businesses that hire developers usually have enough funds to configure their own server, or to have a better equipped shared hosting account. A few hours of development is much more expensive than the difference between cheap bulk hosting and your own supplier-managed dedicated server. By using a scalable, programmer-efficient language like Perl, you save more than just a few hours, if your developers are competent.

As for being faster to code, it's faster for small things to work from one file and insert a few lines of code, than it is to work with a templating system and keep the code and HTML separate.

It is, but maintenance will suck real soon after that. Clean code is more work, but that is an investment that will save time, and thus money, in the future. Only if your business is small and never gets new employees, you can do without code separation and documentation. But most businesses want to grow, and thus have to invest in a stable foundation for future activities. Code mixed with content is a fragile base. (And don't forget that this isn't Perl versus PHP anymore, as you can easily use content and code with Perl. It takes only a few regexes, or one of many CPAN modules, to accomplish this. And, of course, it is possible to cleanly separate code from content with PHP -- just don't expect the result to perform well.)

Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

Perl has many templating systems which work in the same way as PHP. They don't require you to keep the HTML separate.

Regarding ISP limitations and CGI, this person's question made it sound like the company would have their own servers and would not be subject to this problem. With FastCGI more widely available, that's another option for running Perl fast.

Something that PHP users often don't realize is that many ISPs run PHP through CGI. They do this for security reasons. Next time you are evaluating an ISP for PHP, check to make sure they offer PHP through mod_php or FastCGI, not just through CGI.

UPDATE: Also, make sure your ISP's PHP offering includes a code cache, because without one PHP doesn't come close to Perl's performance.

Have you played with the new google labs toy google trends? Try comparing the number of searches for php and perl.

Interestingly, you get different results when you change the order of the terms (perl, php). The relative number of queries remains similar, but the countries change; in particular, some countries show more queries about Perl than PHP.

Update: Minor corrections.

The good news is that, when I put COBOL and perl together, perl showed a decisive win.

If you add Java there, then PHP becomes lower than 50%, and Perl becomes almost nothing.

If you put perl, python and ruby together. Perl started higher, but shows a clear downward trend, when ruby and python are stable. Now the gap is almost gone.

Doesn't mean don't take the job, but 'covert' and 'ninja' raise my hackles. It makes it sound like your employer is the enemy.

If you can do a good enough job with PHP you may gain enough credibility to convince them. Or not. Good luck deciding.

If you think it is dirty to use PHP, then some others will also think it is dirty to use Perl as it is old technology. Bottom line, use the right tool for the right thing.

Perl is certainly not for web any more, but PHP is for web only.

Perl is certainly not for web any more

wtf?

I think it's evident that you can't just say that without explaining it thoroughly.

Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

I recently enjoyed the talks about jifty and webGUI on perlcast...perl and the web have a long and mature relationship

#!/usr/bin/php

these days seems you can hack your way through the system ...not ideal but hardly web