Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re: Another prediction of Perl's demise

by tachyon (Chancellor)
on Nov 25, 2004 at 03:36 UTC ( #410313=note: print w/replies, xml ) Need Help??

in reply to Another prediction of Perl's demise

You gotta love the depth of knowledge displayed by some people.

CGI aka The Common Gateway Interface is a set of rules that describe how a Web Server communicates with another piece of software on the same machine, and how the other piece of software (the 'CGI program') talks to the web server. Any piece of software can be a CGI program if it handles input and output according to the CGI standard, and that software can be written in a wide range of languages. In a web context PHP is just as dependent on CGI as Perl. You can directly hack on the Apache C api with Perl, Python, PHP, etc which bypasses the CGI interface in favour of another interface. Unlike PHP however, Perl sees broad application outside of a simple web context.

Within a web context there is no doubt that PHP is increasingly popular and if the web is where you want to work it would be wise to become familiar with PHP, Javascript, and Java as well as what I presume is a core of Perl, Apache, HTML and SQL.



  • Comment on Re: Another prediction of Perl's demise

Replies are listed 'Best First'.
Re^2: Another prediction of Perl's demise
by revdiablo (Prior) on Nov 25, 2004 at 08:10 UTC
    In a web context PHP is just as dependent on CGI as Perl.

    That's only true if by "just as dependent" you meant "not dependent at all". PHP is very commonly used via an Apache module, mod_php, which does not use CGI. Perl is not tied to CGI either, because we can use mod_perl. We get a performance benefit with mod_perl, as with mod_php, but we also get much more power. Not only is the originally quoted doom-sayer wrong on the face of it, he's wrong on substance too.

      No, to be pedantic, tachyon is exactly right. PHP and Perl both can run either as CGI or as mod_(php|perl). They are both equally dependant on CGI ;)
        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.

      "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.

        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.

      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");

      - apotheon
      CopyWrite Chad Perrin

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

        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.
        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");
        That's not very much code. Or, use CPAN.
        use Slurp; my $foo = slurp("bar.txt", "baz.txt");
        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"; <> };

        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.

Re^2: Another prediction of Perl's demise
by bradcathey (Prior) on Nov 25, 2004 at 03:39 UTC

    Thanks tachyon, good points. Comforting and wise. And yes, I have learned some PHP to deal with a PHP-only wysiwyg editor.

    "Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://410313]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (10)
As of 2017-06-26 19:41 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (589 votes). Check out past polls.