I'm of the prototyping nature -- for what I work on, it's better to deploy quick, rather than to spend too much time trying to optimize without having any idea of your bottlenecks, or what the user reaction to your product will be.

Perl in general is going to be slower in execution than a compiled script -- but this is taken care of by using FastCGI, or mod_perl (of course, bad code will trip you up if you try to use them). All you're really doing is trading off CPU cycles for memory, though.

Learning a new language, just for a project, is a good way to get your feet wet on a new language, but can dramatically slow down the project (as you try to code as if it's another language, and have to debug, learning how to handle a whole new set of error messages). Sometimes, it's more cost effective to just buy bigger hardware.

Now, if you're going to be connecting to another server as a webservice (SOAP, RPC-XML, etc.), I'd suggest that you find out what toolkits the various sites are using, and try to stick with one of toolkits. I don't care what anyone says about SOAP interoperability, it's a pain in the ass. The soap-builders list was recently discussing what they've termed 'impedence errors' between how the various SOAP toolkits map data types from XML Schema to their underlying languages, which can cause odd interaction issues.

If you're writing both sides of the interface -- write the WSDL first, and make sure you write to the WSDL. It's much harder trying to work the other way round.

And as for those articles you cited -- every benchmark is a point in time measure, given a limited set of constraints. You have problems with people writing programs specifically for the benchmark, which may make them less robust. For instance, the top 500 list uses LINPACK. But your real situation may be more network, memory, or CPU intensive. It's like saying 'shirt A fits better than shirt B' ... you have no idea what size the person who who tested the fit.

So, what's best for your situation? Well, like I said, what's a good fit for me may not be a good fit for you. Come up with a goal (execution time for processes, number of concurrent users, etc.), and work towards it. If you don't meet the goal, you can release it as a proof of concept, even if it's not production, and get user input about the interface, while you work on a new version. Unless your requirements are well defined, I find that the first version tends to be junked most of the time, anyway. It's more important for defining the interface, than it is for the underlying code.

I'd think the ASP route is more or less out: it's a pure Windows solution (from your post, it seems you want to run linux.) That being said, I'd say if you are a Windows person, and want to take what comes with it, ASP may be a good choice for the web part, you may need other Windows technology to do the index/searching part.

Speed/scalability should NOT be your concern for making this decision, period. It's pretty difficult to find sites for which perl, php or asp is not fast enough (maybe google, yahoo, ebay, amazon?). When speed/scalability does become a problem, it's inevitably the programming/programmer, not the programming language. That being said, if you choose perl, do try to use mod_perl, it's magnitude faster than perl/cgi.

Now PHP vs. perl. Since you're here, you must know all the good things about perl. PHP is a web centric language, it was especially invented for web programming, so it does make many web things easier, esepecially for beginners. After 5 versions, PHP5 is looking like a decent language, and I'm sure it will get better and better because of its large following. Therefore I don't think you should have much concern if you decide to use PHP for the web part.

However, there are very few decent sites where you don't need other backend processing, this is where PHP is not good: it's not designed for, few people are using it for that, which probably means it won't get better in that aspect (ASP has the same problem). If you want a language that can both do your web stuff and whatever else, then perl is a better choice.

Slightly off topic, but I believe amazon.com does use Perl. I know imdb.com and slashdot.org, two extremely busy sites, do. It just goes to show that your setup is more important than the technology you use.

Back to the question: Since you already know Perl, you'll probably be able to dive into PHP with no problems. However, if you're familiar with Perl there are a few things in PHP that might trip you up, like their "Perl compatible" regular expressions, which take a bit of getting used to.

Also remember that what you are designing now does not necessarily have to be able to stand up to billions of page views. Think of it as a rough draft. If you manage to get even thousands of people using your service per day, you'll easily have the funding you need to convert your code (which should be fairly rigid by then) into a more efficient language - or buy a new server with lots of memory that can brute force its way past almost anything.

Use whichever language is easiest to program in.

http://tnx.nl/php

Juerd++

I normally don't like the VI vs. emacs, Windows vs. Linux, Perl vs. PHP discussions, but for this article i'll make an exception.
Let us just not forget that PHP is very popular and 80% of it users really don't care about these shortcomings because it is just very easy to use.

In all fairness, the author could also have made some points where PHP is better than Perl.

In all fairness, the author could also have made some points where PHP is better than Perl.

There isn't a single thing about the PHP programming language that is better than in Perl. Yes, some things are different, like PHP 5's new OO system, but that doesn't automatically mean it is better.

The things in which PHP excels all have to do with its use as a templating-like language, integrated in Apache. And those are things that Perl doesn't do AT ALL, so a comparison would be weird already. There is no popular PHP-like Apache integration that uses Perl. mod_perl is far too powerful and dangerous to let loose on bulk hosting servers, but PHP lacks the power to configure Apache. mod_php and mod_perl do very different things, while PHP and Perl are both programming languages. A comparison showing which of the Apache modules is better would be wrong.

The author would like to learn where you think PHP is better than Perl, though. And he accepts well written patches to the document in question.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

The speed issues notwithstanding, I don't read anything about your project that would specifically preclude any of the three languages you mention. Large e-commerce sites have been built in all three. I think, in the final analysis, it comes down to personal experience and your own programming "personality." Here's a few thoughts I have:

I have at least a few problems with ASP: 1) it does not meet my requirement of separating executable code from HTML, 2) it is exclusively Microsoft (there are crossover methods like Apache::ASP and Sun's Chilisoft) 3) I'd have to learn VB (too much like the old days).

I have pretty much avoided PHP because: 1) it does not meet my requirement of separating executable code from HTML, 2) lack of 'strickness', 3) too many words--there is a function for *everything*, 4) see the Update from this thread as well as the rest of the discussion.

I like Perl because 1) I know it (fortunately I chose correctly when I decided to learn a server-side language for my web work), 2) it requires me to be a careful programmer (programming has become a hobby for me), 3) and oh...the CPAN modules (I amazed at how a few lines of OO code can eliminate reams of my code and all the headaches), 4) you won't find better support than the Monastery.

The only issue that concerns me about pure Perl/CGI is the overhead, but apparently, though I have never used it and know little about it, mod_perl addresses that.

Whatever you end up using, make sure it is safe, structured, 'strict', uses best practices, and well documented. That will make up a lot of the minuses of any language. Better well-written PHP than poorly written Perl--at least in principle.

PS: Another insightful overview.

As someone who uses both PHP and perl on a daily basis, I feel the need to point out some bad assumptions here.

First, your reasons for avoiding PHP are based on some flawed assumptions. Regarding (1) you can separate HTML from PHP just as you may with perl. While Rasmus does claim PHP is a templating language, there are plenty of PHP developers using template engines (look at the popularity of Smarty in the PHP world if you have any doubts). (2) PHP5 introduced E_STRICT, which operates very similarly to perl's 'use strict'. Additionally, you can set error reporting to either be completely off, show all errors and warnings, or a number of grades in between. Basically, you can get PHP to complain about exactly the same sorts of things perl complains about when warnings and strict are used. (3) can also be considered a benefit; there's little need to add external libraries as they're already compiled into the language. And regarding (4), PHP has not been limited to the web for quite some time; the CLI SAPI has been compiled into PHP by default since version 4.3.0, and was available in the entire 4.x series. While the CLI doesn't have the popularity of the web SAPIs, it is available, and many PHP programmers utilize it (myself included).

Your reasons for choosing perl have everything to do with yourself and your personal preferences, and little to do with the language. One can be either a careful or slipshod programmer in perl -- as in any other language. CPAN and the Monastery are probably the best reasons for choosing perl over another language -- but PHP has PEAR, user comments to the online manual, and a variety of lively mailing lists, making even those considerations somewhat moot. Basically, you should choose the language that suits the problem at hand, and, if possible, that others to whom you have direct access use (i.e., if your co-workers use a language and are proficient in it, you should probably try to utilize that language as you'll have mentors and people who can help debug and maintain your code).

I have at least a few problems with ASP: ... 3) I'd have to learn VB (too much like the old days).

To be fair, ASP doesn't restrict you to a language. If you've already got ActiveStates Perl on Windows, then you have PerlScript. You also get Perl for ISAPI, a technology for speeding web sites under IIS.

Thanks for the clarification. That's reassuring. I've not spent much time with ASP, but if I get into a situation I look into the other scripting methods.


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

If you have a busy site, you won't want to use vanilla Perl CGI. You'll probably want to use the native mod_perl API, or use the CGI interface with Apache::Registry and mod_perl. The difference in speed is significant realtive to standard CGI

I like PHP. I have nothing against it, and use it form time to time, but just like Perl better. Really, there is no real "correct" answer to these questions. It comes down to personal taste. But you know Perl, so maybe that's what you should stick with

The most important issues are probably going to be
-- where are your skills your greatest
-- which languages have existing code in the public domain, or you can license code on the cheap, to do the least amount of wheel reinventing for your project.

Good luck.

Big site with its own dedicated (virtual) server that you can configure and maintain yourself: Perl with mod_perl.

Site on shared bulk hosting where you have to choose between mod_php and mod_cgi: PHP if dynamic programming is necessary for every page, otherwise static pregenerated content with CGI scripts for the less often accessed dynamic pages.

Amazon.com, a huge high-traffic makes heavy use of Perl, but thousands of small web shops are built with PHP. Just the purpose of your site-to-be is no indication for the language to use. I think the most important thing is how skilled the programmers involved are or want to be. PHP is very limiting, and it'll forever keep its users at a beginner's level. Perl on the other hand has a steep learning curve, but allows one to reach a level at which you're no longer scripting or writing dynamic templates, but are actually programming a complex system much more easily.

If you start learning both PHP and Perl at the same time and spend equal time learning them, very quickly will you have become a PHP expert knowing all there is to know. At that point, your Perl skills will be considered merely intermediate. Once you reach Perl expert level, you start laughing at PHP :)

Thanks Juerd. If a site like Amazon works with Perl then my site shouldn't have any issues for now. I am sure Amazon will attract more volume than my site for the next few years...Once the concept works out i can always hire people who are very proficient in this area to improve things...for now I think I will stick with Perl as it gives a lot of flexibility!

thanks for all your feedback!

cheers

SK

It sounds like you'll be learning with either language, so you really are in the advantageous position of deciding where your career might go. If you want to become proficient with PHP, do you web site with PHP. If you want to become proficient with perl, CGI, and mod_perl, do your project in Perl. The Monks are always here for you.

Neither will become obsolete and either one can get the job done. If something tips it one way for me, it's that you already have some Perl experience. If you're new to the web side of things, you'll be exposed to so many new things to learn, you may find comfort in what you already know. You'll likely spend less time with trivial issues if you stick with Perl.

Thanks a lot everyone! This is awesome information. I was skeptical to start this topic due to the Vi vs Emacs nature of the question. However, I couldn't help it because I couldn't understand the advantages/disadvantages if i choose one over the other :)

Now, I have a very good understanding of the issues with ASP/CGI etc. Thanks for those two links, they are really cool! I think the points made on spider etc is very good. Having the flexibility of a flow blow language will be very nice and I guess we can always switch the web-side if things don't work out right!

Best of all I know where to go if i get stuck with mod_perl :)

Thanks Everyone!!!

cheers

SK

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. :-)

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.

You should target all your time into what is basic to have it all working: (imagine that your 6 months have expired, what would you do to have something working?)

Everybody knows that you could start coding something that works in PHP faster than in perl.- That is why PHP exists. But PHP has always some sort of respect towards what is written in perl.

That said, I think that your main target now, is to know more about www working. Concepts that are the same in any language. If you use a site, you are not easily going to know if it is working in C, perl, PHP or in Basic.

It is a must to know what you are going to need to manage your site: sessions, databases, multitier layers, TCP-IP, etc. So, it would help a lot if you face it with some language in mind.

We use to forget our new language. The best of all: Open Source. Yes, the language of the people, not a companies language. That is: you could start standing on the shoulders of a working project like http://krang.sourceforge.net/ , for example. That uses one of the most outstanding perl modules & technology: CGI::Application.

Then, you should start studying the code and the web concept. As well as subscribing to the Krang forum to check your doubts and learn other concepts.

Little by little, as long as you understand how it is all working, you'll be adding what you need to make it your own site. The benefit is that as long as you are studying it, the project keeps on growing in complexity, with you riding over it all the time!

In that way, you might spend your next 6 months in the right direction.

Forget about the speed of your code. But build everything with mod-perl in mind. After you have something working fine, you shouldn't bother about speed. You shouldn't even notice the difference. Read about Krang and you'll learn that it actually has mod-perl in mind. But is not exclusive to that.

.{\('v')/}   C H E E R   U P !
 _`(___)' ___a_l_b_e_r_t_o_________