No, to be pedantic, tachyon is exactly right ... They are both equally dependant on CGI

Indeed, I never said they weren't. I only meant to point out that neither one is dependant on CGI at all. So yes, their dependence on CGI is equal, because it's 0 for both.

The only difference between mod_cgi and mod_perl/mod_php is what level the CGI interface is decoded at. The browser itself sends the same data no matter what.

Under mod_cgi, the server guarentees certain environment variables and how the standard filehandles are setup. The server might modify the output headers slightly (though it definately won't under NPH).

Under mod_perl/mod_php, the server has already done much of the work of deparsing the browser's request, and may significantly alter the output before the response finally goes back. With mod_perl2, the potential for output-munging is even greater with the use of filters that are applied after the CGI or main handler has run.

Are you confusing HTTP with CGI? CGI is a specification allowing communication of a HTTP request and a HTTP response between two programs by means of a combination of environment variables, STDIN, STDOUT and STDERR. mod_perl doesn't set or use those env vars, and I doubt that mod_php does, so neither use CGI at all.

mod_perl doesn't set or use those env vars

Not for handlers, no. It does when you run Perl code through the perl-script handler. Also, the standard filehandles are never directly connected to the browser, though you can usually pretend they are.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

On the other hand, some tasks that are absurdly easy to accomplish in PHP are a relative (though very minor) pain in the arse in Perl. For example, try comparing the process of getting the contents of a text file into a variable in Perl vs. PHP. Hint: In PHP, you only need one function in a short line of code.

$foo = require("bar.txt");

use IO::All;
$content = io('file.txt')->slurp;
    # or
io('file.txt') > $content;
    # or
use File::Slurp;
$content = read_file( 'filename' );
    # or any number of include methods in Mason/Template/Embperl...
[download]

The things that IO::All makes absurdly easy include (and aren't limited to):

• Tied files.
• Appending to file.
• Appending to our original string with a new file: $content << io('new.txt');
• Inserting the contents of a web page, even a secure one, into a string.
• Running a flat DB.
• Reading files backwards.
• Doing socket communication; clients and servers.
• File stats and File::Spec support.
• and so on; most can be done in one line.

Sad, but I just gotta...

Who is Your Mother? :)

---

Examine what is said, not who speaks.

"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

use Fatal qw( :void open close );
sub slurp {
   local $/ = undef;
   my ($s, $file);
   open $file, $_[0];
   $s = readline $file;
   close $file;
   return $s;
}

$foo = slurp("bar.txt");
[download]

That's not very much code. Or, use CPAN.

use Slurp;
my $foo = slurp("bar.txt", "baz.txt");
[download]

Your "that's not very much code" example is, in terms of a size ratio, a staggering increase in "effort". If you happen to be writing something involving a lot of tasks that compare similarly between the two languages, the difference can really pile up.

I'm afraid I don't really know anything about the Slurp module, and don't feel like looking it up right now. Thus, I can't really comment on the second example at this time.

In any case, my point was that some things are easier in PHP. Perhaps there are easier ways (or means that have roughly the same ease) to do these things in Perl, but if so, I certainly don't know them all. I suppose there's always the possibility that I'm just Wrong, and all PHP sucks ass horribly beside comparable use of Perl, but I tend to think that's not so — else the PHP language would never have been created in the first place.

- apotheon
CopyWrite Chad Perrin

For example, try comparing the process of getting the contents of a text file into a variable in Perl vs. PHP. Hint: In PHP, you only need one function in a short line of code.

This really has nothing to do with the point I was making, but I'll bite. I'll agree that many things are easier in PHP. This flows from PHP's philosophy of shoving everything in as individual built-in functions. I have many problems with this philosophy, but it's pretty clear that it makes many things easier.

The example you chose, though, isn't quite as dramatic as you make it to be. As others mentioned, the best answer (in terms of effort) is probably to use File::Slurp, but it's not very difficult to do in core Perl, either:

  my $foo = do { local (@ARGV, $/) = "bar.txt"; <> };
[download]

Now, the PHP code is simpler and more obvious, but the Perl is no great feat. It's common enough that most good Perl programmers should recognize it immediately. Again, I'm not trying to say your main point about PHP being easier is wrong, but I don't think this is the best example of it.

Granted, there are surely better examples. I'm not precisely what you'd call a "good Perl programmer", though. At this point, only the obvious is likely to occur to me, because I just don't have the depth of knowledge necessary to conceive of the unobvious in Perl (usually). C'est la vie.

In any case, even if it's not the "best" example, it is still an example that is somewhat effective. By recognizing that there are other, better, examples, you only make my point more concrete.

In any case, my point is mostly predicated upon the notion that often the programmer's time is more valuable than whatever benefits you may gain through more time-intensive code implementations. The fact that PHP can often save hours of programmer time is its most compelling point of value. I, too, find the PHP philosophy of "too damned many tools" to be troublesome, but that doesn't change the fact that sometimes its benefits outweigh its detriments.

There are also times that Perl is easier, of course. In those situations, there's not much to be said for using PHP instead.

It doesn't seem that we disagree, in the final analysis. My only reason for bringing it up was as a reminder that sometimes the "overall better language" isn't the better language in a given instance, and if you have the resources and capability to choose either of them for a given job, you should just use the right tool for that job. Don't limit the tools you will use if you don't have a compelling reason to do so.

- apotheon
CopyWrite Chad Perrin