PHP vs PERL vs PYTHON
- Thread starter Toaster
- Start date
Carenath
Cynical Dragon
It will come down to personal preference IMO. Not being a coder with any length of experience, I could not judge which of the three languages is the best choice.. and you'll find that some members here can be quite vocal in their support/detraction of each.
Perl - Slow, resource-heavy, for ad-hoc PHP-like execution of individual files and scripts, it requires Apache or another CGI-aware server. Differences between the Windows and Linux perl libraries cause problems (or they did back when I was messing with it).
PHP - Not without its problems, easier to learn than Perl, easier to write bad and insecure code. Supports ad-hoc execution of individual scripts (CGI-like operation) in FastCGI mode.. supported by any server that supports FastCGI for better performance than Apache's mod_php or regular CGI.
Python - Reportadly easy to learn, but tends to force the developer to treat the web application like a compiled application rather than a collection of scripts.. implies that CGI-like operation is not possible, though applications written in Python can be run as FastCGI, and thusly supported by nginx and other FastCGI aware servers.
These are just some observations and opinions based on my limited experience with the three language sets. Naturally I tend to prefer PHP because I can write an application like vBulletin, where different .php files, are called to perform different functions in the overall application.. like a collection of CGI scripts, but without using SlowCGI and taking the performance hit.
This preference is reinforced by the design philosophy behind the nginx webserver.
nginx only supports FastCGI for serving web applications.
php's interpreter can be run as a FastCGI application itself, allowing nginx to simply pass all .php files to the interpreter and output the result.. similar to how Apache's mod_php plugin works to provide the same feature.
To my knowledge, neither Perl nor Python's interpreter can be operated this way, so applications written in Perl or Python have to be self-contained FastCGI programs with their own webserver for which nginx can proxy requests to and from. This makes the use of Perl or Python for small simple CGI-like scripts, using the nginx (or any other FastCGI aware server), pointless.. in this case I'd write them as a compiled C++ program instead.
Of course if you dont mind taking the resource penalty that comes with running Apache or another application server (its what Apache is best at) or use nginx as a proxy in the foreground as many do, Python, PHP and Perl (in that order) would be my preference.
Perl - Slow, resource-heavy, for ad-hoc PHP-like execution of individual files and scripts, it requires Apache or another CGI-aware server. Differences between the Windows and Linux perl libraries cause problems (or they did back when I was messing with it).
PHP - Not without its problems, easier to learn than Perl, easier to write bad and insecure code. Supports ad-hoc execution of individual scripts (CGI-like operation) in FastCGI mode.. supported by any server that supports FastCGI for better performance than Apache's mod_php or regular CGI.
Python - Reportadly easy to learn, but tends to force the developer to treat the web application like a compiled application rather than a collection of scripts.. implies that CGI-like operation is not possible, though applications written in Python can be run as FastCGI, and thusly supported by nginx and other FastCGI aware servers.
These are just some observations and opinions based on my limited experience with the three language sets. Naturally I tend to prefer PHP because I can write an application like vBulletin, where different .php files, are called to perform different functions in the overall application.. like a collection of CGI scripts, but without using SlowCGI and taking the performance hit.
This preference is reinforced by the design philosophy behind the nginx webserver.
nginx only supports FastCGI for serving web applications.
php's interpreter can be run as a FastCGI application itself, allowing nginx to simply pass all .php files to the interpreter and output the result.. similar to how Apache's mod_php plugin works to provide the same feature.
To my knowledge, neither Perl nor Python's interpreter can be operated this way, so applications written in Perl or Python have to be self-contained FastCGI programs with their own webserver for which nginx can proxy requests to and from. This makes the use of Perl or Python for small simple CGI-like scripts, using the nginx (or any other FastCGI aware server), pointless.. in this case I'd write them as a compiled C++ program instead.
Of course if you dont mind taking the resource penalty that comes with running Apache or another application server (its what Apache is best at) or use nginx as a proxy in the foreground as many do, Python, PHP and Perl (in that order) would be my preference.
Perl isn't outdated. It's still actively developed, and new software is still written in it. It was, and still is, very good at text processing, and that's what most of Web development comes down to. The only "problem" with Perl is that it was designed as a replacement for half a dozen smaller Unix tools, so if you're not familiar with any of them, Perl has a lot of.. idiosyncrasies. But it's still plenty powerful and fairly consistent.
PHP is a mess. It's a bad clone of Perl shoehorned into C syntax. Almost everything about it is shoddily done, and it's pretty much too late to fix now. Its only benefit is that it saves you a few lines of httpd configuration if you need a speed boost. But quick one-page scripts can usually be CGI without any problems (and can be made persistent without much trouble), and big applications should be using some framework or other anyway.
Python is great. Use that if you don't already know Perl. CGI works fine, there's a mod_python if you really don't want any structure, there's Django if you want to build an app with a lot of stuff done for you out of the box, and there's Pylons if you want to build an app but like to tinker.
There's also Ruby, which is sort of a middle ground between Perl and Python. Haven't used it much, though. It has Rails, which is like Django (and which most web frameworks were inspired by), as well as a handful of others with different approaches.
And of course real men use C. And butterflies.
Perl is neither slow nor resource-heavy. In fact, it beats PHP in memory usage in most of those benchmarks, and its speed is equivalent on average.
I developed Perl on Windows for use on a Linux server for quite some time and never ran into any problems. Of course, I'd suggest just not developing Perl on Windows in the first place.
Wrapping a single Perl script to run as FastCGI for nginx or lighttpd is not difficult. This sort of thing is a minor concern in the first five minutes of development, but deployment is generally something you set up only once.
Anything can run as FastCGI. It's entirely language-agnostic, and it will always be faster than CGI.
CGI is also language-agnostic. It's just as easy to write CGI Python as it is to write CGI Perl. Your application is only an application if you write it as such—which you should.
Which renders the entire application loosely-coupled and harder to maintain for no gain. Most such PHP applications also end up with a bunch of files that something like general-script.php?actual_action=newreply (like the page I'm on right now, newreply.php?do=newreply), which is a cheap hack around the real routing system you'd get with any MVC framework.
This is completely wrong, and you clearly have no idea how FastCGI works. There is no independent web server; the application needs only to have an event loop that checks a few environment variables instead of running once and exiting.
Here is a Perl CGI script:
Code:
#!/usr/bin/perl
use strict;
use warnings;
print "Content-type: text/plain\n\n";
print "Hello, world!\n";Here is a Perl FastCGI script:
Code:
#!/usr/bin/perl
use strict;
use warnings;
use FCGI;
while (FCGI::accept() >= 0) {
print "Content-type: text/plain\n\n";
print "Hello, world!\n";
}You can easily write or find a wrapper script that will let you run Perl CGI without any modification to the original code.
Yes, because writing a C++ application is clearly easier than using a 40-line FastCGI wrapper script you can find online. Or spending ten minutes to see if the latter is even feasible.
Last edited:
Xenofur
Get off my lawn.
Nothing is best. Period. One can most likely argue that PHP sucks for most anything, but neither is python hard to read (get an editor with decent highlighting) nor is Perl outdated.
The main problem with your question is that there are many different tasks one might want to perform and for each task there is a good tool. What task are you interested in?
nrr
Member
Emphasis mine. Why comment on it if you have nothing to bring to the table?
Perl has several ways to expose forward-facing interfaces for Web applications. Off the top of my head, I can think of mod_perl, CGI.pm, SCGI, FastCGI, and even other possible solutions built using HTTP::Server::Simple and/or Net::Server.Carenath said:
On the framework front, there are literally dozens of ways to get things done. If you want to embed Perl in HTML, you can use embperl or HTML::Mason or any countless other modules. If you want a full-stack framework along the same lines as Rails, you can use Jifty or Catalyst. If you want the Perl version of Camping, look at CGI::Application.
In addition to that, there are modules that are more specialized, like REST::Application.
I write Perl (and HTML::Mason) to pay the bills, and I'm looking to pick up maintenance on a couple of modules on CPAN, so I know a thing or two about this.
It's easier to learn, granted, but it's an absolute bitch to master. If you want to master PHP, learn C; as Eevee has already said, PHP is the bastard child of Perl and C.Carenath said:
The first remark about Python's tendency to force the programmer into treating Web development as iterating through compilation stages, etc. is patently false. mod_python provides an internal handler to expose this functionality to the programmer, and on the server-agnostic front, you can write a CGI/FastCGI/SCGI application that uses something like string.Template, Jinja, Mako, or any number of the available templating engines.Carenath said:
That said, anything that can read from stdin and write to stdout can be used in a CGI-like fashion. I can even do this with Lisp and Scheme, and I often do.
... and this is rampant fanboyism for nginx. I personally use Apache/mod_perl for my Perl-written things because it actually sucks less to configure and maintain. Does it eat up more resources than nginx or lighttpd? Certainly.Carenath said:
In the grand scheme of things, though, do I save myself time, money, and agony by not having to poke around /proc to make sure I can allocate the amount of file descriptors required to dispatch FastCGI requests or similar? Certainly.
I'd rather toss more money at hardware for the problem than turn the whole mess into a gigantic timesink. There're always a few pints waiting for me at the pub that would otherwise be pretty lonely.
The moral of the story: Use what the fuck you want, do your homework, and make informed decisions.
Last edited:
Runefox
Kitsune of the PC Master Race
I'm not a developer or anything, but I think the major thing to take into consideration when saying "Oh, well, Python is better than PHP" or what have you is how many people actually know how to code in the language to begin with. If it's just you, then sure, go ahead with Python or Perl (it isn't as outdated as you think, as has been said); Just remember that the web server needs to actually support it. If you're planning to recruit, though, there tends to be a far greater stock of people familiar with PHP than Perl or Python, particularly since most bundled web apps like PHPBB and many CMS'es tend to be coded in PHP - Hence a large interest in learning it.
Of course, like I said, I'm not a PHP/Perl/Python developer. At least, not at the moment. My skills would put me into the "hacker" category, rather than "coder".
Of course, like I said, I'm not a PHP/Perl/Python developer. At least, not at the moment. My skills would put me into the "hacker" category, rather than "coder".
And most of those people never grow out of the amateur stage and have no idea what they're doing. I've seen very, very few competent PHP programmers, and most of them avoid it and consider something else their main language.
PHP is a bad language. Programmers who prefer it are likely to be bad programmers. I have been over this before.
What on Earth does choice of language have to do with this? And what do you perceive to be the distinction?