Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Perl and Infiltrating PHP Workplaces

by Withigo (Friar)
on May 23, 2006 at 22:18 UTC ( #551246=perlmeditation: print w/replies, xml ) Need Help??

Esteemed Monks,
Like many monks before me, I am presently wrestling with alluring temptations(i.e.,actual job offers) beckoning me to turn away from the path of the righteous(TMTOWTDI) and do PHP coding.
But man cannot live by bread($$$) alone.

I am wondering if any of you could share any of your successes of starting at companies who are either doing significant work in PHP, or moving towards being locked into PHP, and being able to covertly replace PHP with Perl over time. Or instead of covert-ops, perhaps getting to be on the company's elite-Perl-ninja squad. It is a truism that many companies have no idea what technologies they ought to optimally use, but instead just use whatever is marginally compatible with their current systems, as setup by previous architects and administrators, or even worse use whatever some fast talking salesman in a suit sold to upper management.

PHP is easy to learn, but has a shallow pool of potential problems for which to provide a solution(die CMS/AJAX frameworks, die!), while Perl is beastly complex and arguably has a stated goal of being infinitely extensible(via Parrot). Those latter virtues of Perl are often deemed to be the gravest of vices in the eyes of the uninitiated(i.e., the unintelligent), and so PHP is chosen for being faster and cheaper("good" is no longer even an option).

I would be especially gladdened to hear any war stories about PHP failing to meet some need which was eventually done(right) in Perl. (Bonus points for stories in tone.)


Replies are listed 'Best First'.
Re: Perl and Infiltrating PHP Workplaces
by TedPride (Priest) on May 23, 2006 at 22:51 UTC
    Well, PHP is horrible for sorting any sort of nested structure (I haven't yet figured out how to do it), and figuring out the proper format for regex under PHP is also a pain. Plus, everything just seems to take twice as long to type. On the other hand, PHP can be inserted inside your page, so I've found it easiest to write simple things in PHP and difficult things (or things that have to be called by cron jobs) in Perl. This way I don't have to mess with templating systems.

    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.

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

        It is certainly correct for you to say that you want keep logic and presentation aprt from each other. PHP violates that, but Perl is obviously not a solution either. The best is something like JTSL.

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

Re: Perl and Infiltrating PHP Workplaces
by Juerd (Abbot) on May 24, 2006 at 09:33 UTC

    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.

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

"faster and cheaper"
by perrin (Chancellor) on May 23, 2006 at 23:34 UTC
    FYI, Perl came out faster than PHP in every benchmark I've ever seen, including the one Yahoo did. But maybe you meant it's faster to code, which I wouldn't know.

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

      Juerd # { site => '', 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. :)


        (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.

Re: Perl and Infiltrating PHP Workplaces
by duff (Parson) on May 24, 2006 at 02:25 UTC

    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.

      Some people really want stick to Perl, some want XP points and cheap cheering.

Re: Perl and Infiltrating PHP Workplaces
by dragonchild (Archbishop) on May 24, 2006 at 04:36 UTC
    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!".

    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?

      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 => '', 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?

      I am just being honest, and I think your comment is pure stupid.

Re: Perl and Infiltrating PHP Workplaces
by perrin (Chancellor) on May 24, 2006 at 14:24 UTC
    You might find this useful.
Re: Perl and Infiltrating PHP Workplaces
by Booger (Pilgrim) on May 25, 2006 at 23:42 UTC

    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.

Re: Perl and Infiltrating PHP Workplaces
by TedPride (Priest) on May 24, 2006 at 05:04 UTC
    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.

    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 => '', 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.

Re: Perl and Infiltrating PHP Workplaces
by ambrus (Abbot) on May 24, 2006 at 18:46 UTC

      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.

        Stupid, that was because it picks top countries based on the first term. Think! That's why you have a brain.
      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.
Re: Perl and Infiltrating PHP Workplaces
by girarde (Hermit) on Jun 04, 2006 at 20:40 UTC
    Do not go into a job with the thought that you may rightly treat management as children, using redirection and manipulation to bring them along, however much you may know better. Whether they are fools or not, if you take their money they obtain the right to be treated as adults.

    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.

Re: Perl and Infiltrating PHP Workplaces
by Anonymous Monk on May 26, 2006 at 00:23 UTC

    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


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

      Juerd # { site => '', 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


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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://551246]
Approved by Paladin
[Lotus1]: I was here

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (11)
As of 2018-06-18 17:55 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (110 votes). Check out past polls.