Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Not Inciting a Holy War, but...

by Kozz (Friar)
on Jun 17, 2000 at 22:15 UTC ( #18661=perlquestion: print w/ replies, xml ) Need Help??
Kozz has asked for the wisdom of the Perl Monks concerning the following question:

...I've got a friend who runs the ISP where my company's domain is hosted, and where I do all my perl scripting.
He's much more versed in writing BASH scripts, and more recently PHP. However, he doesn't know alot about Perl, but insists that anything (Web/CGI-related) I can do with Perl, he can do better with PHP. He cites things like automatic form-variable creation and other features of PHP which make it so great for an embedded scripting tool. He also complains that my Perl scripts create an unnecessary load on his server (no mod_perl) which could be avoided or reduced if I used PHP instead. (Of course, there are actually *many* instances of many of my scripts running on this one server; my company has developed websites for many domains hosted on this same server, thus many use my perl scripts.)
Usually his complaints are precipitated by a single oopsie on my part, such as creating a nightmare-ish deep-recursion which temporarily brings the server to its knees for perhaps 20 seconds. I'm by no means a perfect programmer, of course.<BR.
So I have my faults, but that doesn't make PHP superior to Perl. What would you tell this person?

Comment on Not Inciting a Holy War, but...
Re: Not Inciting a Holy War
by mdillon (Priest) on Jun 17, 2000 at 22:42 UTC
    oh, yeah. automatic variable creation is GREAT! for those of you who aren't familiar with this, PHP's default settings cause it to look for incoming GET, POST, and COOKIE variables in a specified order and import them into the global namespace. so, if someone calls your script with foo=bar as a parameter, the variable $foo in the global namespace will be 'bar'.

    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.

Re: Not Inciting a Holy War
by redmist (Deacon) on Jun 18, 2000 at 00:41 UTC
    In the Disadvantages of Perl? meditation I started, I got alot of well thought-out responses saying, among other things, that there is a purpose for every language and a language for every purpose... I think that this applies in this situation because both langs probably have advantages over each other in certain areas.

    So to answer your question, I would ask him about specifics. If he is just being a PHP nazi, he won't have anything to say...and if he actually has some reasons, it should be an interesting discussion.
Re: Not Inciting a Holy War
by le (Friar) on Jun 18, 2000 at 02:19 UTC
    Well, I am currently developing a web application for our helpdesk. It relies on a MySQL-database and the frontend is done in PHP. The app is (at the moment) used for customers mail queries. Right now, I consider porting it to Perl, and this is what came my way:
    • 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.
    Just my .02 cents.
      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

Re: Not Inciting a Holy War
by cbraga (Pilgrim) on Jun 18, 2000 at 04:45 UTC
    After developing a large amount of PHP pages I've come to the conclusion that PHP's best advantadges aren't. It mingles with the html code, and in the beginning it's cute, when all your HTML is simple.

    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.
Re: Not Inciting a Holy War
by merlyn (Sage) on Jun 18, 2000 at 05:14 UTC
    Comparing PHP to CGI/Perl is pointless. Compare PHP to either Apache::EmbPerl or HTML::Mason, and you are starting to get a fair comparison.

    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

      This node was taken out by the NodeReaper on Thu Aug 11 22:22:45 2005 GMT
      Reason: [kutsu]: Delete: Trolling in a 5 yr. old thread

      For more information on this node visit: this

Re: Not Inciting a Holy War
by JanneVee (Friar) on Jun 18, 2000 at 16:02 UTC
    Other replys on this thread has been on the point. Perl is more mature than PHP. The only pro and con of PHP it is designed for just that it is used for. Webpage scripting.

    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!

Re: Not Inciting a Holy War
by Anonymous Monk on Jun 19, 2000 at 10:24 UTC
    Tell him "If you can pay someone else to rewrite all my code, and pay me for my time off and my training, and pay someone else to keep my show on the road while your training, I'll have a go at it. On the other hand, ask him how much his costs would be reduced by you using PHP, and go him halves.
Re: Not Inciting a Holy War
by Anonymous Monk on Jun 19, 2000 at 14:01 UTC
    Ya.. PHP quite handy .. if you need only simple embedded page.. A complex embedded page is pointless .. However, if you r an experienced perl programmer, you will also find that to create your own simple embedded page and parse it is quite easy and enjoyable .. and maybe even faster (with mod_perl) depending what you like it be.
Re: Not Inciting a Holy War
by buzzcutbuddha (Chaplain) on Jun 19, 2000 at 21:36 UTC
    I don't know PHP very well, but I can't imagine that it has the bevy of Systems Administration and Networking
    tools that Perl has. I'd challenge him to create a website that allows you to administer the server from
    the web using only PHP, and you'll do the same via Perl.
The lighter side of the Holy War
by Corion (Pope) on Jun 20, 2000 at 13:40 UTC

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

Re: Not Inciting a Holy War (PHP faster than CGI/Perl)
by rodry (Beadle) on Sep 21, 2000 at 22:05 UTC
    I have invested a lot of time learning and buying books on Perl and I think it is a very mature, multipurpose language. Best of all, the support you get from people that do work in Perl (like the monks here) is outstanding.

    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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://18661]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2014-10-02 08:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (51 votes), past polls