Possible Future for PHP

Original author: Frank Karlitschek
  • Transfer

Image taken from wikimediafoundation.org

From a translator : this post is a free translation of an article A possible future for PHP , written by Frank Karlitschek, the founder of ownCloud and the developer of the open-source product for creating cloud storage.


If you look at the latest statistics, OwnCloud is one of the largest open source projects written in PHP. Most of you know that PHP is used to implement the server side of OwnCloud. We use other technologies, such as C ++ and Qt for desktop clients, Java for Android applications and Objective-C for iOS, JavaScript for the web interface and much more. But the heart of OwnCloud is a server component that is based on PHP 5.3 or higher ...



There were several reasons for choosing PHP:
  • The main objective of OwnCloud is to provide everyone with their own cloud server. PHP is a technology that is available on most web servers, operating systems and platforms. We also make hosting of OwnCloud servers much easier, because they are written in PHP.
  • PHP is a scripting language, which means that one tar archive will work on all platforms, and there are no complicated compilations and assemblies.
  • PHP is very well known. Many people are familiar with PHP. And even developers who do not know PHP can learn it quite easily. This is very important for an open source project, because the level of requirements for participants should be as low as possible.
  • PHP is powerful and fast enough if used in the right way. Many large web projects such as Wikipedia, Facebook, WordPress and partly Yahoo are written in PHP. Thus, you can do a lot on it. Unfortunately, bad code is also relatively easy to write. But more on that later.
  • There is a huge ecosystem of libraries, components / drivers available for PHP. For an open source project like OwnCloud, this is very cool because it means you don't have to write everything from scratch. We stand on the shoulders of giants.


PHP is not the most “hit” programming language in the world. In fact, the opposite is true. He has a relatively bad reputation. Personally, I have never been a big fan of choosing technologies based on the fact that it is “cool” or it is “modern” or it is “in fashion”. I think that there are different technologies for different areas, and they should be evaluated objectively and they need to be selected without the participation of emotions. So I don’t understand the religious discussions about why tool X is always better than technology Y. I think that all of these are the right technologies to work, of course, after a fair assessment of the wisdom of using them.

So I'm still very happy with this decision to use PHP. So far, we have not encountered major architectural or technical problems that we could not solve with PHP.

But does this mean that PHP is perfect and I am very happy with everything? Of course not. PHP was developed in the mid-90s, at a time when no one could imagine the web as it looks today. Some of the interesting features of the time turned into a nightmare today. There is much that needs to be improved, and I think that even the core developers of PHP will agree with me here.

Some obvious flaws:
  • Security. PHP itself is not safe, but it is an opportunity to write beautiful and safe code. PHP decided to implement a rather naive approach to security and does not support the developer too much in writing safe code. In fairness, everyone was naive about web security in the 90s. Thus, there are not many features in PHP that help the developer write safe code. For example, confusion with databases, many people still do not use bind variables, which probably allows the appearance of SQL injection. And input filtering for XSS and other possible problems must be resolved by the developer manually. There are extensions and libraries that can help solve all these problems, but they are not part of the language / kernel or do not completely solve the problem.
  • compilation / configuration. Just for fun, run the ./configure script to compile PHP and look at all the compilation options. Now look at the options that can be set in php.ini by the server administrator. On the one hand, this is good, because the administrator can enable and disable the lion's share of functions in PHP in a rather trivial way. But for a PHP developer, an application that should run on all available PHP-enabled servers is a nightmare. You never know which features are available and active. In OwnCloud, we have a lot of code that depends on the environment and the runtime, and checks that everything works as it should, or adapts to it as necessary. This, unfortunately, is not what you call a stable platform and a good OS abstraction.
  • There are some inconsistencies in the functions and class names. Underline is sometimes used, sometimes CamelCase. Some features are available in a procedural style, and some have an OO API, and some even both. There is much that needs to be cleared.
  • Static typing. Of course this is a matter of taste, but sometimes I really want to have more static typing; I really would like to have a little more static typing in PHP. Guess what the following code does if you have a file named "0" in the directory

while ( ($filename = readdir($dh)) == true) $files[] = $filename;

I really want to see PHP moving to the next level and improving some of these shortcomings in the future, because most of them really deserve it.
But it is very important to do it right.

The last article in ArsTechnica and Apple is pushing for the implementation of Swift as the successor to Objective-C, and here I imagine how the next generation of PHP can and should be done.
Maintain backward compatibility or fix your flaws? - Apple Swift

Now there is an old, and frankly, very naive approach. The core team of developers of the programming language simply releases a new incompatible version that fixes the shortcomings of the old version. Examples are Perl and Python. The problem is that it is almost impossible to rewrite most of the software projects written in these languages ​​in order to make them compatible with the new version. Thus, you end up working with two versions of a programming language / framework / application for a very long time. And some applications work on the old version and will work on the old version. Different library dependencies are sometimes available for only one version.

Migration is very difficult and cannot be completed in parts. Please see Perl6 and Python 2/3 for an example of what a nightmare this could become. Both exist for a very long time and many projects are “stuck” somewhere in the middle of the migration route.

A more positive example is C ++. It is still very different from C, but it’s good that you can use it mixed inside the application. Thus, C developers of the 90s can use new interesting C ++ functions in one part of the application, without having to rewrite the entire application from scratch.

Apple is moving forward with Swift as the successor to Objective-C, which I think is very smart. After all, this is a completely new language, but it works in the same runtime. This means that the developer can take the existing Objective-C application code and just start writing new Swift functions or replace some parts of the old code with others with the new Swift code. Ultimately, this compiles into binary, which has no new runtime dependencies compared to Objective-C.

I hope that PHP will do what makes it possible to significantly develop and improve the language, but, nevertheless, providing a smooth migration experience, not like with Perl and Python, when they released completely new incompatible releases.

It would also be a good solution if PHP 6 or 7 introduces a new opening tag, for example Here are some ideas for improvement that I would like to see:

  • Security. There will be no more _GET, _POST, _SERVER arrays, instead of them the correct API will appear, which can be used to filter all incoming data. (Translator Note: Currently there is a filter_input that is supported by PHP 5> = 5.2.0)
  • Database. PHP supports many different database APIs. Some of them are very old, but they are incompatible in use. All must be standardized so that there is only one OO API. I personally would like to see PDO as a basis.
  • 32 / 64bit. Anyone who has ever tried writing a PHP application that runs on 32-bit or 64-bit operating systems will recognize that variables, especially integer ones, behave differently. I understand that these are echoes of C / C ++, but this is a really bad idea. I do not want to have different pieces of code that need to be checked independently.
  • Safe_mode, open_basedir and other ancient concepts will leave (Translator Note: The safe_mode option was marked depricated in 5.3.0 and removed in 5.4.0)
  • Most of the compilation and execution configuration options will be removed . All PHPNEXT environments should be as close and stable as possible.
  • Typing. It would be great if PHP introduced additional static typing, such that the variable could be declared as bool or int. And if something else is used in it, an exception was thrown.
  • To always use Unicode strings


Some of these improvements have been implemented in Hack, which is a kind of separate PHP branch developed on Facebook. Hack has a really interesting concept that is developing in the same direction. They also use the new tag "
I hope that the dream of a more modern and cleaner PHP, including a smooth migration path, will come true in the next few years.

Obviously, we at OwnCloud will not be able to start migrating to this new PHP mode until 95% of all PHP installations start working with the new version. It will be easy, but will require an additional 3-5 years.

By doing large projects, such as WordPress or OwnCloud, you will actually be able to move to a cleaner and more modern language. But more importantly, PHP will be ready to challenge the future.

UPD: added a note about removing safe_mode in 5.4.0. Thanks Sway for the tip :), also added a note about filter_input , thx AmdYfor the comment .

UPD2: fixed some errors in the text, thanks hDrummer for the comments provided.

Also popular now: