Having watched PHP develop over the years, it started out as a very simple Perl replacement, but then has been slowly adding features of Perl one by one, but three to five years later. In another five years, it'll probably be where Perl is now.

So why wait? With Perl, you get a mature language, and a language that works as well off the web as on. And HTML::Mason and everything else in the CPAN make leveraging other people's implementation a snap for nearly any common task.

PHP - it's "training wheels without the bike".

-- Randal L. Schwartz, Perl hacker

"Training wheels without the bike" -- I love it!

I'm gonna remember this post for a long time to come...

hehehe

however, since PHP also stores variables for system settings in this same global namespace, some of which are not always populated, it is pretty easy for a user to spoof your script by passing in variables with the correct names.

for example, when a script is running under an SSL server, the environment variable HTTPS is set to 'ON'. however, in other circustances, it is not set at all. so, if you have a custom PHP function that you want to behave differently based on whether it is called by a script under an SSL web server or not, you can't just check the value of HTTPS because it may have been passed in by the end user with HTTPS=ON. to get around this, you either have to disable the automatic variable creation by unsetting your GPC_ORDER (which is a very kludgy thing to do on a per script basis), or check to make sure that HTTPS=ON isn't in HTTP_GET_VARS, HTTP_POST_VARS, or HTTP_COOKIE_VARS, thereby eliminating the value the namespace munging had in the first place. that is just idiotic, IMHO.

i myself use PHP fairly often, so i don't by any means think it is horrible, but it definitely fails in a number of areas where Perl shines (and vice versa, occasionally).

however, since PHP also stores variables for system settings in this same global namespace, some of which are not always populated, it is pretty easy for a user to spoof your script by passing in variables with the correct names.
I wondered about this a few months ago, it seems like a pretty insecure system if you ask me. Wouldn't it also be possible for someone to use serious memory on the box by making a request like:

foo.php?foo=bar&baz=foo&bar=foo&morefoo=foo etc. I suppose it wouldn't be so much of a problem with GET, as surely it is limited by the size of an environment variable (at least on UNIX that is). What about POST though?

IMHO PHP may be ok for web/CGI-type apps, but you can't make a nice runnable "normal" program with it, can you? Therefore I would imagine that learning Perl is a better use of your time.

IMHO PHP may be ok for web/CGI-type apps, but you can't make a nice runnable "normal" program with it, can you? Therefore I would imagine that learning Perl is a better use of your time.

Completely acknowledged. There is a standalone version of PHP, but I don't see any use for it if you can have Perl. Perl is a much more mature language.

IIRC, a year or two back, this very problem in PHP was bandied about quite a bit in 2600 Magazine. Although most of the h@xor kiddies had some pretty funny ideas about what PHP actually was (there was a popular notion, again IIRC, that it was some sort of throwback automated phonebook or address book application-- I think this was entirely based on the fact the PHP and phone both start with PH) folks were pretty knowledgable in how to exploit it, even if they weren't clear what they were exploiting.

Just food for though, I guess.

The Autonomic Pilot; it's FunkyTown, babe.

• PHP is much faster than plain Perl/CGI. (No wonder, it's an Apache module.)
• Mod_perl might be as fast as or faster as PHP (I'm currently figuring out.)
• Developing in PHP is quiet easy: besides the already mentioned automatic variable creation, I find it very handy, that you can put your PHP code directly into the HTML page. You don't have to wrap all your HTML into print() calls.
• I really miss a PHP-CPAN. Because the app is more or less an email client, I have to deal with attachments and stuff. Finding a working, MIME-handling PHP class was really a pain, Perl has great MIME modules.
• PHP can natively do HTTP Authentication. Simply send a 401 header and find username and password in special variables.
• If you need database support, you have to recompile PHP (which is rather annoying). Perl just needs the proper DBD-module.

One comment I would make regarding:

Developing in PHP is quiet easy: besides the already mentioned automatic variable creation, I find it very handy, that you can put your PHP code directly into the HTML page. You don't have to wrap all your HTML into print() calls.


Check out Embedded Perl. This allows you to incorporate your perl program logic within your html.

Like most Perl situations, there is more than one way to do it. If you have lots of program logic, and a small amount of html, look at CGI.pm; if it is the other way around, EmbPerl. Either takes advantage of the performance of mod_perl.

I cannot comment on some of the more sophisticated solutions such as Mason.

Ken

But when I wanted to do some serious design I found programs such as frontpage treat php tags as junk, and I ended up having 100% code php files and the whole page layout in a separate, editable file in which I perform variable interpolation. It seems kind of silly to use an html-embeddable language without embedding it.

I am now developing a meta search, in which several sites' search outputs are parsed. It uses threads, tons of regexps, tons of hashes, and makes http requests. That's four things PHP can't do.

All in all, PERL (and mod_perl) feels like a pro language, and PHP feels amateur. When your PHP script dies, it spits lots of errors to the browser. Shameful. mod_perl returns a 500 error and logs the messages.

But when I wanted to do some serious design I found programs such as frontpage treat php tags as junk

Wel to answer this, don't use FrontPage it's a ugly program...
Better program everything yourself. Don't use this argument to promote perl over php. First program in what you feel comfortable with and start comparing languages when you kind of master one language reasonable good!

My opinions may have changed,
but not the fact that I am right

If you are working with non-programmers who may be called upon to do some design work then Frontpage is a great program. If your server supports the Frontpage extensions then Frontpage is a great program. Don't knock it just because its Microsoft.

He can probably do simple things fast with PHP. Faster than some of us can do the same things in Perl. (IMHO) But when it comes to complex scripts and maintanance on these complex scripts Perl is the best choice!

However, in realizing how "expensive" CGI is on a server (specially if you make DB connections, according to Merlyn), tecnologies like PHP become more and more attractive to web developers.

Some of you may point to mod_perl, which I am now aware of. However, in my particular case, where I rely upon third party hosting services, mod_perl is not an option as most (if not all) hosting services won't allow you to write modules to the web server.

I plan to continue using Perl since I have grown fond of it and have invested lots of time learning it. But I will also begin learning PHP and consider it seriuosly when developing a web based application in the future.

Rodry

We've all seen the arguments about the new kid on the block, PHP, but bbnews supplies us with the real reason why we don't do stuff like PHP.

Note: BBnews isn't actually a reputable news site :)