Why PHP is out of date
In 2000, I was a big fan of PHP. I started using it immediately after the official release of version 4.0 in April. At that time, apart from him, there were only 4 alternatives for creating websites.
1) C - too complicated for a frequently changing project. The compilation took a lot of time, there were few free tools, and paid ones did not fit into my budget. Too verbose. Dependency management was a tricky business.
2) Java is better than C, but still verbose and long compiled. Dependency management was a tricky business.
')
3) Perl is almost as good as PHP, only without a package management system. On CPAN there was a set of modules for all occasions, but they had to be downloaded and installed. Dependency management was a tricky business.
4) ASP - almost as good as PHP, only it was a tool from Microsoft, and its use would suck me into their dear world.
For three positions, I wrote: "Managing dependencies was a tricky business." For me, this was a key moment in PHP. His philosophy was “all in one.” Such as now, package management systems was not there. Now there are handy things like Bundler for Ruby and Leiningen for Clojure. But not in 2000. Even Linux package management systems have become better since 2000. And the “all-in-one” system solved the problems of package management in PHP. But now this advantage does not matter.
PHP has other strengths. It is optimized for the web, but it is not unique today. For those who were afraid of C, he proposed wrappers for functions C. But in other languages today is still simpler :
Over the past few years I have worked in various corporations ( Wine Spectator , Timeout ) on their systems. Basically it was PHP and the symfony framework. I already criticized them earlier . It seems to me that people who use PHP in corporate tasks today have forgotten why they liked PHP before. You can tell what advantages he had in 2000, but today? It is slow, clumsy, the systems have become too complex, the uncompiled essence of the language gets in the way of trying to make big projects on it. If you are doing a CMS in a project that needs 100 servers, you will have to deploy CMS entirely on each of the 100 servers.
What innovations in the PHP world exist today?
People add pthreads when there are no tools for working with concurrency in the language. For contrast, take a look at Clojure .
Complicated code caching system for symfony .
The comments add annotations - instructions that control the execution of the program. It seems to me that this is a bad idea. If you need to model interacting problems (cross-cutting concerns), you need to choose a language that makes it elegant, rather than relying on a raw solution like annotations.
List of changes and fixes that need to be made because of a long history of controversial development.
Swollen memory management .
Ritual programming is a bunch of unnecessary instructions, with no advantages like checking at the compilation stage. In 2000, one of the arguments in favor of PHP was that it did not have too much code typical of Java. Do we want PHP to completely evolve into Java ?
The love of complexity for the sake of complexity .
No settings for management and configuration . This is similar to the lack of package management systems that PHP suffered from — unlike Ruby, Python, or Clojure. But in PHP, no work is being done to remedy the situation - this is shifted onto the shoulders of system administrator tools like Chef and Supervisor.
The abundance of monkey patches (substitution of methods and values ​​of attributes of classes of the program during its execution). traits are like monkey patches in ruby, but traits are even harder to work with, as well as track and debug them.
Ambition, overtaking the language itself . As Fabien Potsier said, PHP has some great features. What is strange. It’s as if we had inserted Ferrari’s powerful engine into a rusty Fiat.
An infinite number of functions introduced for convenience.
And I can not but remember the famous essay: " PHP: a fractal of bad design ."
When PHP has some cool stuff (Streams and Iterators), they turn out to be nailed to the language, rather than integrated into it. They are not perceived as part of the philosophy of language. Instead, Ramus Lerdorf says things like:
In comparison, Yukihiro Matsumoto describes Ruby like this:
The lack of deep insight from the leaders of the PHP development team leads to ugly manifestations, in particular, to the lack of instructions for novice programmers on how to write good code in PHP.
In 2004, Ruby On Rails suddenly appeared, and promised to save everyone from the complexity of Java and the confusion of PHP. At that time it was a big improvement. It was structured and elegant, inaccessible to PHP. But today even Rails is outdated . Today, Ruby and PHP work equally well with parallelism. They were developed when the computer processors had one core, which over time became faster and faster. But the future obeys the law of Amdal , and in this direction they have nothing to offer. jRuby is the future of Ruby , one of those languages ​​that is worth considering today. But there is no language about which one could say “this is the future of PHP”.
I wish people could answer me the question “why would I choose PHP for myself today?”. In 2000, the arguments for him were convincing, but today there are no such reasons. The world has changed, and now there are dozens of the best opportunities.
1) C - too complicated for a frequently changing project. The compilation took a lot of time, there were few free tools, and paid ones did not fit into my budget. Too verbose. Dependency management was a tricky business.
2) Java is better than C, but still verbose and long compiled. Dependency management was a tricky business.
')
3) Perl is almost as good as PHP, only without a package management system. On CPAN there was a set of modules for all occasions, but they had to be downloaded and installed. Dependency management was a tricky business.
4) ASP - almost as good as PHP, only it was a tool from Microsoft, and its use would suck me into their dear world.
For three positions, I wrote: "Managing dependencies was a tricky business." For me, this was a key moment in PHP. His philosophy was “all in one.” Such as now, package management systems was not there. Now there are handy things like Bundler for Ruby and Leiningen for Clojure. But not in 2000. Even Linux package management systems have become better since 2000. And the “all-in-one” system solved the problems of package management in PHP. But now this advantage does not matter.
PHP has other strengths. It is optimized for the web, but it is not unique today. For those who were afraid of C, he proposed wrappers for functions C. But in other languages today is still simpler :
Julia’s problems at present are a relative lack of libraries. But in a language, it is enough just to interact with existing libraries from C. Unlike other languages, you can call C code without writing a line in C, and therefore I think that libraries for Julia will quickly catch up. In my experience, I managed to use 5,000 lines of C-code after 150 lines of code on Julia.
Over the past few years I have worked in various corporations ( Wine Spectator , Timeout ) on their systems. Basically it was PHP and the symfony framework. I already criticized them earlier . It seems to me that people who use PHP in corporate tasks today have forgotten why they liked PHP before. You can tell what advantages he had in 2000, but today? It is slow, clumsy, the systems have become too complex, the uncompiled essence of the language gets in the way of trying to make big projects on it. If you are doing a CMS in a project that needs 100 servers, you will have to deploy CMS entirely on each of the 100 servers.
What innovations in the PHP world exist today?
People add pthreads when there are no tools for working with concurrency in the language. For contrast, take a look at Clojure .
Complicated code caching system for symfony .
The comments add annotations - instructions that control the execution of the program. It seems to me that this is a bad idea. If you need to model interacting problems (cross-cutting concerns), you need to choose a language that makes it elegant, rather than relying on a raw solution like annotations.
List of changes and fixes that need to be made because of a long history of controversial development.
Swollen memory management .
Ritual programming is a bunch of unnecessary instructions, with no advantages like checking at the compilation stage. In 2000, one of the arguments in favor of PHP was that it did not have too much code typical of Java. Do we want PHP to completely evolve into Java ?
The love of complexity for the sake of complexity .
No settings for management and configuration . This is similar to the lack of package management systems that PHP suffered from — unlike Ruby, Python, or Clojure. But in PHP, no work is being done to remedy the situation - this is shifted onto the shoulders of system administrator tools like Chef and Supervisor.
The abundance of monkey patches (substitution of methods and values ​​of attributes of classes of the program during its execution). traits are like monkey patches in ruby, but traits are even harder to work with, as well as track and debug them.
Ambition, overtaking the language itself . As Fabien Potsier said, PHP has some great features. What is strange. It’s as if we had inserted Ferrari’s powerful engine into a rusty Fiat.
An infinite number of functions introduced for convenience.
And I can not but remember the famous essay: " PHP: a fractal of bad design ."
When PHP has some cool stuff (Streams and Iterators), they turn out to be nailed to the language, rather than integrated into it. They are not perceived as part of the philosophy of language. Instead, Ramus Lerdorf says things like:
We have protected properties, abstract methods, all this garbage, about which your computer science teacher told you. I don't care for all this shit.
In comparison, Yukihiro Matsumoto describes Ruby like this:
For me, part of the meaning of life is joy. Programmers rejoice when they can concentrate on the creative aspect of programming. Ruby is designed to make programmers happy. If you do work fast and fun, that's good, isn't it? Your life is getting better. I want to solve everyday tasks using a computer, so I write programs. Using Ruby, I want to concentrate on what I am doing, and not on the magic rules of a language like having to start a program with the words “public void something something” in order to then say “print hello world”.
The lack of deep insight from the leaders of the PHP development team leads to ugly manifestations, in particular, to the lack of instructions for novice programmers on how to write good code in PHP.
In 2004, Ruby On Rails suddenly appeared, and promised to save everyone from the complexity of Java and the confusion of PHP. At that time it was a big improvement. It was structured and elegant, inaccessible to PHP. But today even Rails is outdated . Today, Ruby and PHP work equally well with parallelism. They were developed when the computer processors had one core, which over time became faster and faster. But the future obeys the law of Amdal , and in this direction they have nothing to offer. jRuby is the future of Ruby , one of those languages ​​that is worth considering today. But there is no language about which one could say “this is the future of PHP”.
I wish people could answer me the question “why would I choose PHP for myself today?”. In 2000, the arguments for him were convincing, but today there are no such reasons. The world has changed, and now there are dozens of the best opportunities.
Source: https://habr.com/ru/post/258767/
All Articles