I think he has some insightful points on why Perl is loosing to PHP on the low-end. -Tom]
From: Bogart Salzberg <[EMAIL PROTECTED]> Subject: mind share Date: Sat, 15 Jan 2005 11:56:07 -0500
[...]
A little bit of background might help you to know where I'm coming from. I started out as a web designer. I always hand-coded HTML, then I learned JavaScript, then Perl, then PHP. Now I do mostly web database applications, with a smattering of rapid-fire scripts here and there for small-time e-tailers and corporate clients. I also do a lot of general webmastering, which is why my rant is web-centric. I was one of those guys whose very first program was executed in a web browser (by a web browser). For those of us who have never taken a CS class, the web is an obvious gateway to learning computer programming.
My first attempt at executing a Perl program was to copy one line by line out of a CGI book, upload it to my economy hosting account and try to run it as a CGI. (My computing power was limited to a Mac 6100 running OS 7). I got '500' over and over and over. I'm sure it was something ridiculously simple, like a missing semi-colon, permissions error or bad shebang line. But as a novice, I felt helpless. It didn't help that I had no access to the server error logs. The ISPs tech support people definitely DID NOT want any part of helping me debug my CGI. I put Perl away for many months, until I got a G4 and could start running Perl in the Terminal.
This is why I hope that Perl will become more friendly to novices, especially the budding web geeks. The toe-hold one needs to become self-sufficient (and self-teaching) in Perl is not very big, but it is still too elusive to many a newbie. PHP is utterly at home in the web medium. If I had to recommend a programming language to a curious young web geek, I would be hard-pressed to recommend learning Perl first. Unfortunately, it seems that for many of these folks, PHP is like the college town where they settle down and never leave. The buzz in the PHP community right now is self-sustaining, to the point where they believe (and why not) that they can make it do anything. One look at the new object orientation in PHP 5 (borrowing heavily from C++) will tell you that this language is rapidly maturing and improving.
Bogart
From: Bogart Salzberg <[EMAIL PROTECTED]> Subject: Re: [Boston.pm] mind share Date: Fri, 14 Jan 2005 13:33:27 -0500
[...]
I wrote this because, basically, I couldn't help myself. I love Perl but I live with PHP, and I have to let off some steam. I am sending this to you two because you asked. However, I'm not sending it to the list because of Tom's request to save the venom for meeting time. Since I can't go, I would like to contribute these words to whatever discussion might ensue. So, Tom, I guess I'm entrusting this to you for the time being. Please share it if and when that makes sense.
I would like to suggest a few points of discussion regarding Perl vs. PHP, from a web-centric point-of-view. I'm not sure how many of you are in web development, but I am interested in Tom's idea of possibly addressing some of the differences as "areas of improvement" for Perl or for the way Perl is taught. I am definitely *not* trying to convert people to PHP. (No crusades). So here is a sort of outline of *possible* trajectories for a discussion.
I. Comparison of the syntax and basic features Perl and PHP:
-There are many similarities and a few striking differences (e.g.: hashes and scoping). Perl offers an elegance and fluidity of expression which is utterly lacking in PHP. Yet it's possible that 'idiomatic' Perl (which I consider a form of poetry) is too much of a turn-off for novices and code management types. PHP forces one to write in a more 'straightforward' manner, with more blocks, more variables and more function calls.
II. Comparison of Perl and PHP for basic web scripting:
-PHP is *friendlier* to the novice web scripter. It is immensely more helpful, for example, to get a response such as "parse error, line 34" than "500 Internal Server Error". Obviously, "use CGI::Carp qw/fatalsToBrowser/;" levels the field. But even that requires a certain level of sophistication. All you need to get some PHP executed is a '<?', a '?>' and a '.php' suffix.
-PHP can be *embedded* in HTML while Perl can not (with the exception of HTML::Mason and the like). Sometimes web scripting in Perl seems like the ant (the dynamic elements of the page) carrying the gigantic leaf (the static HTML strings). Heredocs can only go so far.
-PHP is *easy to modularize*. Code snippets can be linked in with a simple 'include file.php', and they are executed as if they were inline. This is perfect for headers, footers, navigation, ad rotation, etc. Mason and friends are Perl's answer, but setting up Mason and mod_perl is not for the faint of heart (or the novice).
-PHP is *convenient* (and also grotesquely obese) because it offers something like 1,000 built-in functions. There are built-in functions for setting cookies, managing sessions and saving session state, sending headers, sending mail, formatting dates, etc. Also, (and this is huge), form parsing is built in. All cookie, get, post, server and environment variables (plus uploaded files) are dumped into global hashes. (They can also be dumped as individual variables into global namespace, but there are obvious security concerns). CGI.pm is an enormously helpful module, but it's nice to know that PHP can get along without a 'sidekick' that has it's own language and is maintained separately.
III. Comparison of Perl and PHP for web applications.
-PHP has MySQL support built in. Again, DBI.pm and the various drivers are no less effective, but the built-in functions make it easy and integrated. Building DBI and DBD::mysql (even if you have enough access to do it) can be frustrating. On the other hand, 'PHP/MySQL' is almost a single word these days, and ISPs are falling all over themselves to support it. Many ISPs also offer 'PHPMyAdmin', a pitifully slow but still very useful open-source MySQL admin tool written in PHP.
IV. Comparison of CPAN and PEAR.
-I've never needed to use PEAR (PHP Extension and Application Repository) because PHP has so many features built in. This, I believe, is the key factor in why PHP is more popular than Perl. It's a philosophical difference. Perl and CPAN take a light, collaborative approach that encourages innovation and fresh perspectives from anyone and everyone. Personally, I am delighted by this egalitarian bent. However, it means that every new module is a new API with its own (more or less) idiosyncratic style of naming, data handling, object orientation, etc. After a while, one gets used to this and I think it results in a more flexible programmer. However, for novices, (and when I'm in a hurry), this can be a big turn-off. With PHP, many of the oft-used peripheral functions are built in and have the full support of PHP's centralizations, such as error handling and documentation.
V. Comparison of php.net and perl.com, perl.org
-This one is, unfortunately, not even close. php.net is a comprehensive resource containing not only the complete (and searchable) PHP documentation, but also user-contributed comments pointing out hour-devouring pitfalls. It's also an attractive, easy-to-use web site. The perl docs online are reprints of pods. They are often better-written (longer, too), but on the whole not organized to take advantage of the web medium. I have often had my question answered quickly at php.net. As with CPAN, the perl knowledge-base is more widely distributed and I have often resorted to Googling some arcane error message from a failed 'make'.
VI. Other comparisons of Perl and PHP
-It would be nice to compare Perl and PHP in the context of command-line utilities, daemons and things of that sort, where it seems that Perl holds a distinct advantage. However, in my case, I've never bothered (or been bothered) to develop one of these in PHP. While PHP is the lingua franca for some enterprises, I can still write and run one-time text-munchers in Perl. That is, as long as my clients' ISPs support it. Some are clearly falling behind, with old 5.6.
VII. Conclusion: Daydreaming
-Synthesize Apache, mod_perl, HTML::Mason and MySQL into the most powerful web application platform the world has ever seen. Clearly there are significant obstacles to standardizing and encapsulating the cooperation of these four components. Each component's interoperability with other outside components would suffer, and perhaps a culture clash would be inevitable. However, wouldn't it be nice if ISPs were hawking '3M' (mod_perl, Mason, MySQL) like they're now hawking 'PHP/MySQL'? Obviously, these components can be combined now. But you need an almost religious devotion to mod_perl (it seems, from my limited interaction) to make it work for you. And Mason is not the same without it.
If you have read this far, thank you.
Bogart Salzberg
_______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
