About PHP vs. Perl

Started by ipt, Aug 09, 2022, 12:19 AM

Previous topic - Next topic

iptTopic starter

Hi! There are some questions:
I have been writing in PHP for quite a long time, but now I began to pay attention that in many large companies Perl is more in demand than PHP. Yes, and in the reviews I read that it is allegedly faster than php (in the speed of script execution), by the way, is this really so or is there really no difference?

Then I read about the horrors of the pearl, like the 500th error or the difficult processing of data that came from forms. I tried some modules , yes, they fix the whole thing, but will they be hosted? Or can you put them there yourself?

And one more thing - is it a good idea to keep all scripts in cgi-bin, or are there some workarounds and more elegant options? In general, of course, after php it is not very convenient that you cannot shove a regular html page into this directory.


Modules that do not require compilation can simply be placed next to the script and called by the full path. A module that requires compilation can be installed for yourself if the hosting provides development tools.

As for PHP vs Perl, I can say one thing... PHP is already a serious language (although some of its features are cute), but it also has a visible simplicity. As a result, all would-be webwriters start their crafts in PHP. Therefore, the number of leaky, crooked scribbles in PHP is many times greater than in Perl. Those. in fact, an active attempt to lower the level of the programmer to enter the language for PHP brings the expected result - the loss of the image.

At the same time, you can write in PCP, and you can write very seriously. I speak as a Perl programmer with 9 years of experience =)
As for perl, it's 50% a regular expression language... which was borrowed by a lot of people (including PHP), and even Unix console utilities are slowly abandoning POSIX regexp by switching to pearl ones. So it is worth getting acquainted with the language at least from this perspective.

As a result, I agree with the previous post - if there is enough PCP, write on it. If you have time and desire - learn Perl - it will not be a minus, a fact. On the contrary, it will give a lot of exp =))
Calling a pearl is already other matter. Let's just say - by the principle of calling, Pearl does not differ from PHP (for example, for Apache it happens through the handler), the difference is made by the web server itself.
The standard scheme is that the php handler is assigned to the file extension, while perl and other CGI handlers need to be called through the ScripAlias folder. But, the web server has given the means to change this principle, even available through .htaccess.

For Apache, I advise you to read http://httpd.apache.org/docs/
If you manage the web server yourself, then in my memory there were 2 modules for Apache - embedded perl solutions ... one for mod_perl, the other for working with a regular perl.
Well, for errors ... each server has an error_log. If the hosting provider does not give access to this file in one way or another, then change the hosting, because the file is very useful.


The main difference between Perl and PHP
The very nature of Perl and PHP is different. Perl is a programming language — a universal tool for solving a very wide range of tasks. Perl was not developed specifically for Web programming.

PHP was originally intended for the development of Web applications.
He tries to combine the power of a full-fledged language and the advantages of a highly specialized tool. In search of a compromise, PHP acquires a number of controversial qualities.
The core of the language

Perl, like any full—fledged language, has some core - a set of functions and rules that do not depend on the platform, operating system and other circumstances. PHP has practically no such core. Hence a number of PHP features.

The set of PHP functions that the programmer has at his disposal depends almost entirely on the provider. (The "right" providers always write with which options their PHP was built.)

This difference is very noticeable. For example, if a website is developed using Smarty, then it will not work on any hosting provider hosting. And this happens only because the Smarty device uses a POSIX extension of the regular expression mechanism.

If your PHP application is written using functions that hosting provider hosting provider does not provide, or you have used libraries that depend on such functions, then it is often impossible to expand the set of PHP functions yourself.

Perl is more stable in this sense. It's the same everywhere and Perl code is much more portable.

Number of functions
PHP provides (potentially) a great many functions. At the moment there are more than 3000 of them. On a real hosting you will find about 1000 of them. Such a wide range of expressive means does not benefit the language.
Different programmers know different sets of operators. This makes it difficult to read someone else's code, exchange code, and develop together.

Perl provides the programmer with a limited set of standard tools. This disciplines the programmer and facilitates the exchange of code and experience. At the same time, the programmer is not at all constrained and can always get the required capabilities by connecting the appropriate module.

It just so happens that externally, programs in Perl and PHP are somewhat similar.
We can say that if a person knows a little bit of Perl, then he knows a little bit of PHP, but if a person knows Perl well, then he still knows PHP only a little. The converse is also true.

I will list some particularly expressive differences.

Of course, it was possible to provide an unimaginable number of PHP functions only at the cost of lengthening their names. This could not but affect the syntax of the language. What is called pop in Perl is array_pop in PHP. What is in Perl — join, in PHP — implode. Solving the same task in PHP is usually more cumbersome.

Let's write a function that returns three values (1, 2, 3).


# function
sub a { return (1,2,3) }
# call
($a, $b, $c)=a();


# function
function a() { return array(1,2,3); }
# call
list($a, $b, $c)=a();

In PHP, the construction turns out to be more heavy.

Besides, PHP doesn't even smell like a Perl tongue twister.

Replace all hexadecimal numbers in the text with their decimal representations.




create_function('$t', 'return hexdec($t
  • );'),
# or
$text=preg_replace('/[0-9A-F]+/ie', "hexdec('$0')", $text);

The same action, but even a short PHP code is twice as long as its Perl counterpart.

Maturity of the language
Of course, Perl is a much more mature language than PHP. It is much less susceptible to changes when moving from version to version and is equipped with more advanced development tools.

Suffice it to say that in PHP, the pointer mechanism is in its infancy. Perl passed this stage of development about ten years ago. PHP does not provide such a data structure as an array. (What is called an "array" in PHP is called a "hash" in Perl.) In this sense, PHP is at the awk level.

In a word, PHP will change for a long time, creating a lot of problems for developers.

Adaptability for Web development
When conducting Web development, PHP discovers a number of significant advantages.

Firstly, the PHP interpreter integrates into the Web server, which significantly increases performance.
 Perl is able to catch up with PHP in performance only if you use mod_perl instead of the CGI approach. Most providers will not provide you with such an opportunity.

Secondly, PHP web applications are easier to debug. Error messages are often issued to the client rather than written to error_log.

Thirdly, PHP has a wide range of built-in functions for working over the HTTP protocol. Perl programmers can also get all these functions at their disposal by connecting the appropriate module, but these functions are built into PHP.

However, almost all of these advantages turn into serious problems from the point of view of resource security.

The fact that PHP is embedded in the server makes it difficult to diagnose the source of attacks. In addition, PHP code can potentially carry much greater threats than Perl code.

PHP gives a lot of freedom to the developer — a PHP script can be placed in any directory of the server. But this also creates additional risks. In many cases, due to the inattention of developers, a server visitor gets the opportunity to "upload" not only pictures and other harmless files to the server, but PHP scripts, and this is a very serious danger.

The fact that PHP issues error messages in response to an HTTP request is convenient for the developer. But from a security point of view, this decision has always seemed controversial to me, because any visitor to your site can find out about errors in your programs. And it may be enough for an attacker to find out the version of your PHP to "break" your resource.

In a word, PHP is "sharpened" for Web development better than Perl, but it's very easy to cut yourself on this blade.

Perl has its own documentation system and is provided with excellent documentation in English.

PHP is also well documented. The advantage of PHP documentation is that it is translated into Russian. I would attribute its vastness to the disadvantages.

Code quality
Of course, the quality of the code depends largely on the programmer, but the language can either dictate a certain style to the developer, or discourage.

I have already said above that a large and not constant set of functions does not contribute to the creation of programs that are easy to read, debug, adapt and migrate. But the main problem with PHP, in my opinion, is that this language allows you to mix HTML code and PHP code. In fact, it is a mixture of data and code.

I won't go into philosophy here, but humanity realized decades ago that code and data should be separated. Many elegant solutions have been found for this, from headers and configuration files, to templates and separate data stores. In this sense, PHP seems to be a step backwards; somehow old-born.

But if we put aside philosophy and look at it from an applied point of view, then we won't see anything good either. Combining HTML and PHP code does not improve the readability of either. Accordingly, maintenance, modernization and modification of programs are also difficult.

Of course, this minus (in my opinion) PHP begins to play a significant role only if the web application is sufficiently developed, there is a lot of code and the developers did not put the HTML code into templates or did not separate it in some other way.

But there are disadvantages "embedded" in the language itself.

So, for example, it seems to me very inconvenient how the transfer of parameters to functions is regulated. Whether the parameter will be passed by value or by reference is determined not when calling the function, but when creating it.
The call looks the same in both cases. This is convenient if you are the author of all the functions yourself, and you remember the prototypes of your functions well. But when working actively in a team, this leads to confusion.

The same is the case with functions that return pointers.

In my opinion, this is the biggest of those disadvantages of PHP that cannot be bypassed in any way.

There is no universal correct solution that is better than Perl or PHP. In each case, it's up to you. The answer depends on the scale of the resource, on ambitions, plans and prospects, and on the specific web hosting provider.

I would advise you to do so:

• if the resource does not involve a large load (a personal page, a page of a small company), then it is more reliable to rely on Perl and the CGI protocol;
• if the resource assumes a large attendance, but its budget is very limited, then you can use inexpensive virtual hosting and a PHP engine;
• if the resource is large and you plan to maintain and develop it for a long time, it is better to use expensive web hosting (own north) and Perl under mod_perl. In this case, your code will work for many years.
The resource will grow, you will install a more powerful server, more recent software, and the Perl code will not require major changes and will continue to serve you.

These are, of course, rather crude recommendations. If in doubt, consult a specialist.

In addition, do not forget that there are other development tools besides Perl and PHP.