PHP: fractal misuse

It seems to me that PHP criticism has already become an independent genre. One PHP article alone : a fractal design bad enough to ponder whether it should be used at least for the pizza order page. And if you still have doubts, go, for example, to PHP Sadness .

Is PHP really that bad? I will not prevaricate - I know too many of its shortcomings. In my personal list in the first place is an insane system of references to variables, which:

a) makes the cloning of objects virtually useless and
')
b) still does not allow the use of the function call_user_func (_array) without a hack, which is described in the documentation .

<upd> The hack is described in the comments on the official documentation. I apologize to all those whom I misled. </ upd>

The second place is a completely crazy system of errors. In PHP, there are 2.5 types of errors and at the time of version 7 there are already 2.5 classes of basic exceptions, none of which are in any way related to others except for implementing the Throwable interface ... which is only in PHP 7 and in earlier versions, its use is itself causes an error. And that's not counting the __halt_compiler and exit functions.

In general, everything is bad. But PHP does no less harm to misuse of the language at all levels of development - from system design to solution of individual functional tasks. And that's what I mean ...

Hypertext Preprocessor

PHP is a hyper text preprocessor. In most cases (except very separate ones , the meaning of the existence of which defies my understanding) PHP works in a textual environment, be it a console call or an HTTP request. And he feels great in him, because he has a textual nature .

The main data type in PHP is string. This idea, at a minimum, can bring the presence of a single conversion magic method __toString in the complete absence of hints at __toInt and other scalar converters. If you take a closer look at this case, then the more logical are the arrays, which are actually dictionaries. After all, if we do not have integers, then there can be no indices. But there are string keys, a special case of which are strings containing whole numbers (the existing transformations of the key reinforce this thought). The comparison, which produces unexpected results, also relies on a textual representation (although you should not reassure yourself once again).

The missing type hinting for scalar types and array element types implies that functions take strings, arrays of strings and objects as arguments, and return strings. In version 5.4, arguments can also be functions, and a little earlier, in 5.3, Closure appeared, which are not lines, but called objects. Thus, there are string data and tools for processing them - you can say that this is PHP in miniature. In version 7, scalar types did appear, but look more like an excuse, just like OOP "just like in Java". By the way, about him.

The magic methods __get and __set, which are present in PHP instead of normal getters and setters, at first glance seem like some kind of nonsense. But in fact, they are a very powerful tool that allows you to work with properties dynamically , without knowing the precise structure of the object at the stage of writing its code. It would seem, why is it necessary? If we consider the objects by themselves, then it looks like a meaningless heap, forcing to write the boilerplate. However, if we consider an object as an interface for some external tool (say, an extension or API), then such a decision makes sense. For example, using __get, __set and __call, you can write a very convenient object database manager, interacting with which by calling stored procedures and changing settings.

Equally important is the ability to save the state of an object between script calls using the magic methods __sleep, __wakeup and __set_state. Again, from the point of view of an object as a thing in itself, it is a disaster, breaking the encapsulation in the dust. However, if an object is an interface for something that runs outside of a script, then it is no less logical than a permanent connection to the same database from the example above. PHP was created to die , and in other words - designed for writing scripts, not applications .

Hawk blow

I like both the scalar type hinting, and the limitation of the visibility of the members of the object, and in most cases useless destructors - because theoretically this gives additional possibilities. But their similarity with the constructions of familiar programming languages ​​leads to the choice of the usual approaches to development and further inevitable disappointment in PHP, because they do not work in PHP.

PHP is much more powerful in tactics than in strategy. The logic of his work is similar to the well-known method of fighting against superior forces called “hit-run” (maybe this is why he comes to taste for beginners?). In terms of functionality, he very much relies on extensions , which he has in stock a huge amount. So much so that it usually loads them all on every call (although there is a dl questionable). The latter is a controversial idea, but in PHP it somehow works because basically everything that it loads is interfaces, and not the functionality itself. This, however, does not interfere with the waste of resources, partially eliminating the exception of PHP 7’s deprecated functionality, which significantly improved in speed compared to previous versions, including. But be that as it may, what is allowed to Jupiter is not allowed to the bull. And the bulls, which in this case are the frameworks and CMS, follow the same logic.

For anyone who has dealt with WordPress , it is obvious that this CMS is not the best example. But nevertheless it is one of the most popular CMS, on which as many as 25% of all sites work, according to W3Techs. And that's what happens on almost a quarter of sites around the world. Each HTTP request, including requests to the REST API (and sometimes even requests to styles and scripts), occurs:

1) loading a rather big kernel of the CMS itself, containing a lot of tools, just in case, written in PHP ,

2) download all the plugins, also written in PHP , many of which have considerable functionality and do not care at all to determine whether or not it is needed at the moment.

And all this in order to give an HTML-page of dubious artistic value. This is reminiscent of a woman who paints her time to go to the next store for bread. One can only hope that no one comes to these 25% of sites.

I don’t know how many percent of sites around the world use PHP, but most definitely the vast majority of them also use frameworks. Have you seen Doctrine ? No, they quite seriously wrote the DQL parser . In PHP. This is not to mention the decorators. These guys, by the way, wrote Twig . And also in PHP. I do not argue that these are excellent products, which have been spent on the strength and time of great specialists. I just do not understand, and here PHP. With the same success it was possible to write all this on the shell.

One can argue with my arguments, but there is Phalcon , which, judging by the tests , cuts everyone into a nut. Although this is just a step in the right, in my opinion, direction, but an example is very clear. Why not make an application server on C and work with it from PHP as with the same DBMS, at the same time using FastCGI? Penny hosting, on which the PHP version is not updated, not to install the extension, could have been the cause earlier, and even that is doubtful.

Honestly, sometimes you regret that PHP is turing full.

Conclusion

A reasonable question may arise - why, then, is PHP needed at all, if, as a full-fledged programming language, it is frankly weak. After all, you can write in C. Or in Java. Yes, on anything. In my opinion, PHP allows you to concentrate on the functions of the application itself, separating it from the hypertext interface, which is easy and convenient to develop in PHP. After all, it is convenient to develop database logic using DBMS tools, and user interface logic on JS, Android SDK, and so on. Each tool is good in its place and bad for everyone else.

PHP has a lot of problems that make programming experience very unpleasant. Peresilivanie language - this is not what you want to engage the developer, whose goal is the final product. But PHP is not buried the first year, but so far he feels good. The language itself is improving and new, more meaningful tools appear for it. The truth is, the more innovations occur at the need of the public through thoughtless copying from other languages, the more there are doubts about the benefits of PHP in the presence of these very other languages. This is especially disappointing, given that PHP has a lot of its own potential - unfortunately, not realized.