Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re: Perl/CGI Vs PHP Vs ASP

by weierophinney (Pilgrim)
on May 22, 2005 at 02:53 UTC ( #459303=note: print w/replies, xml ) Need Help??

in reply to Perl/CGI Vs PHP Vs ASP

As you can probably already tell, this request has the potential for starting a flame war... except that you asked it on a perl forum, where you're not too likely to get a lot of dissent. :-)

I use PHP and perl daily. The websites where I work are run on PHP, and the decision to do so was made before I ever started working there. Now that I've been using PHP regularly, I find I like the convenience of access to various CGI interfaces -- the GET and POST hashes, sessions, cookies, headers, etc. Since it was designed with the web in mind, it's all easy.

I still like perl, and have it running my own website. With mod_perl, perl is incredibly fast in a web environment and your objects stay resident in memory, giving some incredible flexibility. You just have to put a little more work into it to get things working correctly together.

Surprisingly, I find myself using PHP increasingly for anything database related because I know already that the database functionality I need is already compiled into the language, and because PEAR::DB is so dang easy to use. This means I use PHP for both web applications and CLI scripting. It works fine in both environments.

I find myself using perl primarily for processing text or when I need to run processes in parallel. Perl makes forking incredibly easy, and with tools like Parallel::ForkManager, it's even easier. As for processing text, well, that's what perl's best at, as far as I'm concerned. The regex engine is so great that many other languages borrow it for themselves (PHP's pcre functions, for instance).

What it comes down to is, what do you know already? You say you're 'decently familiar with Perl,' but in the same paragraph say you haven't done web or database programming using perl -- and the project you outline will have a lot to do with each. I personally feel that at this point you simply have to decide what language you want to learn most -- and then go to it full-bore.

Additionally, you mention you'll be doing a shopping cart. This is not a light project to tackle. Make sure you do a lot of research before getting too involved. Do not store credit card numbers in your database, at any cost -- simply pass them on to a processing agency. You can not afford the liability, period.

P.S. My personal preference when developing a new site, now that I've been using PHP regularly, is PHP. It's what it was designed for, and I find it's easy to just get things done for web-related work when using that language. You have to jump through too many hoops when using perl, even when using standard modules like CGI, to do the simple things like tracking sessions and getting the page parameters. And I'm lazy. :-)

Replies are listed 'Best First'.
Re^2: Perl/CGI Vs PHP Vs ASP
by astroboy (Chaplain) on May 22, 2005 at 09:18 UTC

    Hi weierophinney

    Just curious - I know you ported CGI::Application to PHP, so I'm wondering what you find more convenient in the PHP version. For instance, I don't find PHP's session handling any harder or easier than CGI::Application::Plugin::Session (plus I can chose whether I want my session info in the DB, in memory or the filesystem). CGI::App's header_type and header_pops gives me simple header access.

    Having the database access compiled in the language is a pain. It only takes sixty seconds it takes to install DBI and DBD::<driver> with the CPAN module, I don't have to worry about whether I need to work with Oracle or MySQL next week. Plus, I find Pear::DB excruciatingly slow and tend to use AdoDB when coding in PHP anyway

    Lastly, the clincher for me is CGI::Application::Plugin::ValidateRM. If I could find something like that with PHP, I may just consider switching for good ;-)

    Please don't take this as a flame. I am keen to use your cgi app port the next time I'm on a PHP project - I'm just interested in your rational.

      What's easier about session handling in PHP is that I don't need another module to use it; I can simply use it without installing anything else; if you want to switch to memoery based sessions, it's a single config directive. And you can switch to databases sessions by writing your own session container -- but you simply define the methods for storing and retrieving, while PHP takes care of the rest, like generating session IDs. Basically, it's one less dependency to worry about.

      Header access is really a moot point -- all you have to do in perl is print out your headers to STDOUT; I probably should not have brought that one up. But when it comes to your POST, GET, and COOKIE hashes, again, in PHP you don't need to load another library to get access to those; you simply have them available.

      Regarding database access in PHP, I actually don't use the database functions directly. I install PEAR::DB (which you allude to), which is similar to DBI, as what it does is abstract the calls for the various DB functions, and provides things like prepared statements, convenience wrappers for simple things like retrieving a single value or row, etc. I am aware that it is slower than ADODB, but honestly, on the hardware I use, this isn't that big of an issue. If I want an upgrade in speed, I'll probably switch to PEAR::MDB2 and/or PHP's PDO layer (once stable). Finally, since I control my own servers, I only compile in database support for those RDBMS' that I use.

      (Which brings me to another point: I've seen a number of sites slam PHP for the number of functions it has. However, not all functions are available by default; if you compile PHP to only use the extensions you need, you can cut the number of functions down tremendously. Granted, I've never understood the naming conventions, nor why there are so many string functions that all do similar, but not exactly the same, things.)

      You mention CGI::Application::Plugin::ValidateRM... funny you should mention that, as I finally ported the plugin functionality over to Cgiapp.clas.php in the 1.7.0 release, which happened this past Friday evening (20 May 2005). Bundled with the class is Cgiapp_Plugin_HTML_QuickForm. HTML_QuickForm is a PEAR library for form creation/validation, and is similar in functionality to Data::FormValidator. It still needs a little testing and work -- integration with template systems other than Smarty is currently untested -- but it does work, and it makes form validation in Cgiapp a snap.

      As I mentioned in my bio, the reasons I ported CGI::Application are because it uses a paradigm that fits web development, and my work situation mandates I program with PHP. The combination of the run mode == method paradigm of CGI::Application with PHP is very powerful, and makes for rapid development of reusable and extendible applications -- two qualities I find I need on a daily basis.

      I really cannot make a case for using PHP + Cgiapp versus Perl + CGI::Application; it really depends on the language you're most familiar with, the server environment on which you'll be running your application, your work situation (if relevant), etc. I can make a case for using CGI::Application or Cgiapp -- and that case is made above: rapid development of reusable and extendible web applications.

        Excellent ... look forward to trying Cgiapp out! Thanks.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://459303]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2020-11-26 10:05 GMT
Find Nodes?
    Voting Booth?

    No recent polls found