You are invited to Log in or Register a free Frihost Account!

What happened to Perl?

How often do you use Perl?
 0%  [ 0 ]
more often than not
 0%  [ 0 ]
about half the time
 0%  [ 0 ]
only occasionally
 66%  [ 4 ]
 33%  [ 2 ]
Total Votes : 6

When I look at and other script download sites, I see that most Perl cgi scripts are not current, some having a few years since the last update. Why is that? Has Perl fallen by the wayside in favor of PHP? Is it because PHP is better, or just easierto learn?

What is Perl?
Perl is a stable, cross platform programming language. It is used for mission critical projects in the public and private sectors and is widely used to program web applications of all needs.

I'm mainly wondering if it's safe to use Perl scripts, if they aren't too old or should I always look for PHP scripts to fit my needs. Not a programmer, just an end user but I'm slowly working towards learning PHP in my "old age" of 50-something.
One difference between the Perl community and the PHP community is that the Perl community consists largely of programmers, while the PHP community consists largely of copy/paste-newbies. PHP 'programmers' have taken the art of copy/past-coding to the highest level possible.

Second: PHP is insecure by design, which means every script will need a lot of updates to fix security bugs (which most PHP-users can't discover and fix themselves).

Overall, PHP is horrible from a programming or security point of view. Most commonly used PHP applications are famous for their security holes (phpBB, phpMyAdmin, etc.)

Also see:

The pro of PHP is also its con: it's easy to use. Because of that it attracts non-programmers who copy/past without proper understanding of what the code does.


Have you ever used PHP? If not, take a look at the following features:

1. addslashes() [] function - Most references say to use this to quote data before putting it into a database. Not only is it The Wrong Way To Do It (twwtdi) according to the SQL standard, but different vendors' databases need different values escaped.
2. Magic Quotes [] ini settings. magic_quotes_gpc is the most important one. When enabled, it runs addslashes() on all GET, POST, and cookie input. It is on by default in php.ini-dist, off by default in php.ini-recommended. Which brings up my next point...
3. The programming environment is not consistent. An INI file [] controls the programming environment. Turning on things like Safe mode [] and open_basedir can cause previously working code to suddenly fail. Of course, php.ini-dist has display errors [] turned on by default, so anyone visiting that page will see the location of your file, the line that has the error, and which error it is... Which brings up the next point:
4. Security is secondary to convenience. See Using remote files [], which is enabled in both ini files by default. See also Magic Quotes as described earlier. Reading up on the deprecated Register Globals [] is informative, as it was on by default up until PHP 4.2.0. I've also mentioned display_errors, which is on in php.ini-dist.

Here's a disturbing fact: php.ini-dist is the more ocmmonly used of the two inis, at least for shared hosting. I'll let you consider the implications of that while I summarize things.

To summarize: The PHP team has made a number of questionable decisions over the years that makes it much easier to write a security hole than it should be.


We have a large group of students, staff, and faculty that all have varying degrees of write access to a departmental Apache web server. Every few weeks someone asks why we're not giving people PHP access. Users love PHP because it's so easy; it makes them feel like they're clever programmers. But it seems like security knowledge is never imparted alongside the PHP training. People seem to think it's as benign as plain old HTML. When they ask for PHP I tell them we have a policy about not giving scripting-level access to users without good justification, and they have no idea why that applies to them since "we don't want to do any scripting; we just want to make PHP web pages".


Criticisms of PHP include those general criticisms ascribed to other scripting languages and dynamically typed languages. This list includes criticisms that have been rectified in recent versions.

* PHP originally inserted data received over the network directly into the language namespace ("register_globals"), leading to confusion between trusted and untrusted data, and unnecessary potential for security holes in PHP applications. This behaviour was turned off by default from version 4.2.0 released in April 2002.[9] However, this feature is still being used by some legacy applications[10].
* PHP has traditionally used features such as "magic_quotes_gpc" and "magic_quotes_runtime" which attempt to escape apostrophes (') and quotes (") in strings in the assumption that they will be used in databases, to prevent SQL injection attacks. This leads to confusion over which data is escaped and which is not, and to problems when data is not in fact used as input to a database. [11]
* PHP does not have native support for Unicode or multibyte strings. [12]
* PHP does not enforce the declaration of variables prior to their use, and variables which have not been initialized can have operations (such as concatenation) performed on them; an operation on an uninitialized variable raises an E_NOTICE level error, but this is hidden by default.
* PHP has no namespace support, with all PHP functions sharing the same global namespace.
* PHP's dynamic type conversion could potentially cause problems. Variable types in PHP, although they exist, are transparent to the programmer. Some may consider this a feature, as a variable can change from int to double and back again without extra lines of code. However, variable type errors are not detected at compile-time, and the dynamic-typing behavior lacks full predictability.
* The standard function library lacks internal consistency. Many functions perform relatively similar actions and have different name standards and argument orders. For example, strpos($haystack, $needle) vs. in_array($needle, $haystack), and strcasecmp vs. stristr.

To answer your question:

outofnicks wrote:

Has Perl fallen by the wayside in favor of PHP? Is it because PHP is better, or just easierto learn?

The last option: it's easier to learn.
It's certainly easier to write unreadable code in Perl than in PHP.

OTOH, it's generally easier to write code that gets the job done in Perl than in PHP. It's also a lot easier to write a secure script in Perl than in PHP. Here's why:

1. In PHP, the code is embedded into the page. It feels like a "safe" scripting language that is just for processing your page. With Perl, your scripts are run as programs on the webserver: they have to have exec permission, so it makes the programmer feel more paranoid about security (yes, paranoia is a good thing for a web programmer!).

2. Perl has taint mode. Every piece of data that comes from the user is 'tainted' and must have the safe data extracted from it before it is allowed to be used in anything potentially unsafe.

Perl is both more powerful and safer (when used properly) than PHP. I'd say it's harder to misuse as well, because it almost forces the programmer to have a fairly good idea of what's safe and what's not.

The pro of PHP is also its con: it's easy to use. Because of that it attracts non-programmers who copy/past without proper understanding of what the code does.

Sounds like what I have been saying about VB for YEARS...
qscomputing wrote:

1. In PHP, the code is embedded into the page.

You can generate the full pages from PHP scripts which are "executables" themselves. Ther is no need to put PHP code into an HTML page.
I had a feeling that Perl scripts are at least as safe to use as PHP, I was just wondering why it doesn't get used as much. Probably a lack of capable programmers. The informed responses to my original post tell me to keep using Perl scripts where appropriate, even if they may not be current or newer than a year. One of my most favorite scripts was Genesis, a file manager package which has now gone commercial and is not accessable as limited freeware or shareware. It was just very well written, and useful.
Thanks for the replies!
MrBaseball34 wrote:
qscomputing wrote:

1. In PHP, the code is embedded into the page.

You can generate the full pages from PHP scripts which are "executables" themselves. Ther is no need to put PHP code into an HTML page.

Yes and no; let me elaborate.

When have a PHP file, you can put HTML straight into that file, and only the code within <?php ?> is processed as PHP code. Even if you don't put anything outside of the PHP code, it still feels like you are creating a "page" rather than a "program" to a certain extent.

With Perl, your script file is a script. You have to make it executable and put a line at the top to tell it that you want it to run with Perl. And you can't write your code inside your page like you can with PHP.

My point was, I don't know anyone who uses PHP to create CGIs that begin with #!/bin/php or similar and have their x permission set - whereas with Perl, that's what you have to do. For me, this encourages a mentality of "this is a program that I'm running on someone else's computer, so I better be very careful how I write it", which is something I don't notice to the same extent with PHP. Because of the way Perl scripts are invoked, they feel more dangerous than PHP, even though there is really no difference. Thus, the programmer is more likely to write rigourous code in Perl to escape this "danger", which he is probably less likely to do in PHP because the "danger" isn't as obvious.

This is of course just my personal experience of using both languages. I hope that this clarifies my point.
Related topics
Perl Tutorial links
What happened?
how can i find the perl location?
[RESOLVED] What happened!
Perl server referencing
Perl Support
Perl module request.
What happened to frihost?
Deleting my account
oh no! what happened to jessica simpson?
What is the path to perl?
My posts are missing
Perl Problem - AH01215: Can't locate
Reply to topic    Frihost Forum Index -> Scripting -> Others

© 2005-2011 Frihost, forums powered by phpBB.