A possible future for PHP

Posted by on Oct 2, 2014 in KDE, other, ownCloud | 67 Comments

ownCloud is one of the biggest open source project written in PHP if you look into the latest statistics. It is used for the server part of ownCloudas most of you know. We use other technologies like C++ and Qt for the Desktop Clients, Java for the Android app and Objective-C for iOS, JavaScript for the web-interface and more. But the heart of ownCloud is the server component which is using PHP 5.3 or higher..

There were several reason for choosing PHP:

  • The mission of ownCloud is to enable everybody to host their own cloud server. PHP is the technology that is available on most webservers, operating systems and platforms. So we make hosting of an ownCloud server super easier because it is written in PHP.
  • PHP is a scripting language which means that one server tar file runs on all platforms and no complicated cross-compiling and packaging is needed
  • PHP is very well known. A lot of people are familiar with PHP. And even the developers who don´t know PHP can learn is relatively easy. This is very important especially for an open source project. The bar to become a contributor should be as low as possible.
  • PHP is fast and quite powerful if used in the right way. A lot of big web application like Wikipedia, Facebook, WordPress and parts of Yahoo are written in PHP. So you can do a lot with it. Unfortunately is is also relatively easy to write bad PHP code. But more about this later.
  • There is a huge ecosystem of libraries, components and connectors/drivers available for PHP. For an open source project like ownCloud this is very cool because this means that you don´t have to reinvent everything from scratch. We stand on the shoulders of giants.

PHP is not the most hip programming language in the world. Actually the opposite. It has a relatively bad reputation. I personally was never a big fan of choosing the technologies based on what is cool or “modern” or in vogue. I think there are different technology for different jobs and they should be evaluated objectively and choose without to much emotion involved. So I don´t understand the religious discussions why tool x is always better than technology y. I think it is all about the right technology for the job after a fair assessment of course.

So i´m still very happy with this decision to use PHP. So far we have not seen any bigger architectural technical problems that we can´t solve with PHP.

Does this mean that PHP is perfect and I´m super happy with everything? Of course not. PHP was developed in the mid 90s at a time where no one could have imagined how the web looks like today. Some of the cool features of the time turned into a nightmare today. There is a lot to improve and I think even the core PHP developers agree with me here.

A few of the obvious shortcomings are:

  • Security. PHP in itself is not insecure and it is obviously possible to write perfectly fine and secure applications with PHP. But PHP decided to implement an quite naive approach about security and doesn´t support the developer too much in writing secure code. To be fair everybody was naive about web security in the 90s. So there are a not a lot of features available in PHP that actively support you with writing secure code. The database situation is a mess so a lot of people still don´t use prepared statement which leads to possible SQL injection. And filtering incoming data for XSS and other problems has to be done relatively manually. There are extensions and libraries available to help with all this problems but they are not part of the language/runtime core or are incomplete.
  • compile time / runtime configuration. Just for fun call the ./configure script to compile php yourself and look at all the compile options. And now look at all the options that can be set in php.ini by the server admin. On one side this is cool because an admin can enable and disable a ton for core features in PHP in a very fine granular way. But as a developer of an PHP application that should run on all available PHP servers this is a nightmare. You never know which feature is enabled and available. In ownCloud we have a lot of code that s the environment and the runtime to see if everything works as expected and adapts to it as needed. This is unfortunately not what you call a stable platform and a good OS abstraction.
  • There are some inconsistencies in the function and class namings. Sometimes unerscores are used and sometimes camel-case. Some features are available in a procedural style and some have an OO API and some even have both. There is a lot that should be cleaned up.
  • Static typing. This is totally a question of taste but sometimes I would really love to have a bit more static typing in PHP. Guess what this following code does if you have a file named “0” in your directory

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

I would really love to see PHP moving to the next level and improving some of this shortcomings because most of it is really good.
But it is very important to do it right.

A latest article at ArsTechnica and Apples move to introduce Swift as Objective-C successor triggered my fantasy how a next generation PHP could and should be done. Keep a programming language backwards compatible or fix its flaws? – Apple Swift

There is the old and to be honest quite naive approach. The core team of a programming language just releases a new and incompatible version that fixes the flaws of the older version. Examples are Perl or Python. The problem is that it´s close to impossible to rewrite a big software project to make it compatible with a new version. So you end up with two versions of the programming language/framework/runtime for a very long time. Some applications run on the old version and some run on the old version. Libraries and dependencies are sometimes only available for one of the versions.
Migration is super hard and can´t be done piece by piece. Please see Perl6 and Phyton 2/3  as examples what a nightmare this can be. Both exist for a very long time and a lot of software is stuck in the middle of a migration story somewhere.

A more positive example is C++. It ´s still a very different language than C but the good thing is that it can be mixed inside an application. So in the 90s C developers were able to use the cool new C++ features in one part of the application without the need to rewrite everything from scratch.

Apples move to introduce Swift as a successor of Objective-C is very clever in my opinion. It´s completely new language but it´s running on the same runtime. This means that a developer can take an existing Objective-C application an just start to write the new features in Swift or replace pieces one after another with new Swift code. This than compiles into one binary that has no new runtime dependencies compared with Objective-C.

I wish PHP would do something that makes it possible to evolve and improve the language significantly but still provides a smooth migration experience not like Perl and Python did with introducing completely new backward incompatible releases.

So a good solution would be if PHP 6 or 7 would introduce a new tag to start a php file. For example <?PHPNEXT instead of <?PHP. Both modes are fully supported by the new PHP version and can be used in parallel in the same application or even in the same file. In the NEXT section the new and improved syntax is used.

Here are a few ideas for improvements that I would love to see:

  • Security. Kill the _GET and _POST and _SERVER arrays and introduce a proper API that can be used to filter all incoming data.
  • Database. PHP support a ton of different database API. Some of them are very old but they are inconsistent to use. Everything should be standardized so that only one OO interface exists. I personally would use PDO as a starting-point here.
  • 32bit / 64bit. Anyone who ever tried to write a PHP application that runs on 32bit or 64bit operating-systems will recognize that variables especially integers behave differently. I understand that this is a reminiszense to C/C++ but this is seriously a bad idea. I don´t want to have different code paths which have to be tested independently.
  • kill save_mode, open_basedir and other acient concepts
  • Remove most of the compile and runtime config options. All PHPNEXT runtime environments should be as similar and stable as possible.
  • Typing. It would be cool if PHP would introduce optional static typing. So that a variable can be declared as, for example, bool or int. An exception should be thrown if used otherwise.
  • Always use unicode strings

Some of this improvements are implemented in Hack which is some kind of PHP fork developed by Facebook. Hack is indeed an interesting concept that goes into a similar direction. They also use a new tag “<hh” so that code can be mixed in one file and they improve typing. At the moment it´s not clear how much energy Facebook will invest in the future to push Hack forward and how much adoption it will get outside Facebook. I´m especially worried how open they are for changes that are not important for them, how well and open this is governed. I would prefer an official and more generic approach from the PHP community which will be part of one of the next main PHP releases.

I hope by dream of a more modern and cleaned up PHP including a smooth migration path becomes reality in the next few years.
Obviously we at ownCloud couldn´t start to migrate to this new PHP mode before 95% of all PHP installations out there run with the new version. This will easily take additional 3-5 years.

By doing this big projects like WordPress or ownCloud would actually have a realistic chance to move to a cleaner and more modern language. But more importantly this would make PHP ready for the challenges of the future.

Please leave a comment here in the blog if you have an opinion about this.

67 Comments

  1. Tim Apple
    02/10/2014

    Hey Frank,

    I’m not a coder, but from reading allot and researching different programming languages and such in an effort to find a path of learning. I have been of the opinion that PHP should be avoided.

    But on the other hand, the two main things I use…. my known site and my mailserver with owncloud are all PHP. So where does that get me…lol

    I think PHP will be around and well used for the foreseable future…a long one at that. Until a viable alternative is acceptied by the masses.

    The only non PHP site/system I really like right now is ghost.org…I’ve played around and they are doing good things in Javascript land.

    My 2 cents..

    Tim

    Reply
    • Craig
      02/10/2014

      More like -2 cents. The opinion of a non-coder on programming languages isn’t worth anything.

      Reply
    • Fritz
      02/10/2014

      > I’m not a coder, […] I have been of the opinion that PHP should be avoided.

      Hmmm… Tim, you are not in the minority. People with no coding experience that don’t hesitate to give an opinion. I am a coder, and PHP is a great language to write in.

      There, I cancelled out your opinion. 🙂

      Reply
    • noypi
      03/10/2014

      try google.com, you may like it also.

      Reply
    • jpp
      03/10/2014

      Most of PHP problems are betwwen the keyboard and the screen, as usual. Oldest version of PHP allowed devlopper to do very dirty things. That doesn’t mean PHP is dirty, or will be dirty. As seen on the lastest version, it support more and more PSR and that is good. PHP become clean, so devlopper will begin to be clean. PHP look like to pythonise itself, for the good.

      Reply
      • Craig
        03/10/2014

        No, that’s a silly and trite thing to say, typically repeated by people with nothing more interesting to say (e.g. unskilled amateurs at level 1 of the 4 stages of competence).

        Reply
  2. Morris
    02/10/2014

    I like the proposed changes. Especially cleaning up the core functionalities and move to an OOP API. Also the optional static typing would be really nice. I currently code Java code and it is just awesome who that improves your workload if you know all the types of the variables, parameter and returned values. That also would make the whole code more robust and failure-proof/drops common problems.

    I hope that this come true 🙂

    Thanks for this great post.

    Reply
  3. Christian
    02/10/2014

    Backwards compatibility is one of the great issues which arise all the time. However, there is no definitive answer to that. As far as Java goes this is an issue which has been bothering generations of developers. Sometimes I wish that they had just made a “clean cut” and introduced new features instead of obeying the omnipresent mantra of backwards compatibility. The same goes for PHP.

    @Morris: Java also has some serious flaws which can really annoy you. One thing is type erasure. Note that type erasure has mainly been introduced for backwards compatibility [sic!].

    I think that a static typing system and consistent and uniform OOP API’s can really improve PHP. As Frank mentioned, you will have to sacrifice backwards compatibility for that. But how can you introduce “modern” features otherwise? I personally would love to see a “new” PHP which reflects the advancements in programming of the last few years.

    Reply
  4. Diederik van der Boor
    02/10/2014

    That ownCloud took PHP as choice, makes completely sense to me. You can indeed write good software in PHP, and it can run almost everywhere.

    When you control the environment however, it makes less sense to be to use PHP.

    My major concern with PHP is that it’s a minefield. You have to really know what you’re doing. You know that md5(‘QNKCDZO’) == md5(‘240610708’) in PHP? The answer isn’t ising === either, or strcmp() but hash_compare(). That’s the kind of detail you constantly have to be aware of, so mistakes lie around the corner all the time. You have a minefield of secure and insecure-by-default choices, so you have to be aware of each step you take.

    Though being very extensive, this is a good explanation of all details that are found in PHP: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

    If they can fix that. or provide a migration path, I’d take my hat off. Honestly, the would do the world a great service if that is possible! PHP will be with us a long time, so any improvement is welcome/.

    Reply
    • Nils
      03/10/2014

      Didn’t hear of that string comparison problem before, is that a known bug that won’t be fixed?

      Reply
    • Alex_PK
      04/10/2014

      > You know that md5(‘QNKCDZO’) == md5(’240610708′) in PHP? The answer isn’t ising === either, or strcmp() but hash_compare()

      False. If you use === it’s working perfectly. If you use == you can’t complain for implicit type casting. The problem with that line is that both the results start with 0e, which gets converted to integer, and 0 to any power means zero, making them equal.

      The same goes for the example in the article.

      The correct syntax is:

      while ( ($filename = readdir($dh)) !== false)

      The article’s one is purpousely built to say “hey, look! it doesn’t work!! This is shit!!!”. The PHP manual is quite clear. If the result is false, there are no more files, so you MUST check for exact matching with false. And the “exact matching operator” is === (or its opposite !==), and not == or !=

      The point is that you should not use a language thinking it’s another one. You must use that language syntax and know it.

      Reply
      • Frank Karlitschek
        04/10/2014

        sure. Everyone knows this syntax. But the point of this article is that is would be a good improvement for PHP if optional typing could be used so that mistakes like that can be avoided.

        Reply
      • Nils
        07/10/2014

        It will still work even if you use single quotes or cast them to string. That’s very bad.

        Reply
  5. Anonymous Guest
    02/10/2014

    Aren’t you essentially asking for Hack? (http://hacklang.org/)

    Reply
  6. tux.
    02/10/2014

    Facebook doesn’t only use PHP, they also created their own extension language named Hack.

    Reply
  7. MoRpHeUz
    02/10/2014

    Taka a look at HHVM and HACK. They are evolutions of PHP already being used by the community 🙂

    Reply
    • Frank Karlitschek
      04/10/2014

      Sure. This is even mentioned in the article 🙂
      But I don´t think this should be used until the changes are officially blessed and supported by the bigger PHP community and actually integrated into the next release

      Reply
  8. Laszlo Papp
    02/10/2014

    Hi Frank,

    this is a nice summary, thanks. I am not much of a PHP developer, but I can completely agree with you about the python notes. It is difficult for me to migrate a huge python project over. I have been reading a python book these days (Learning Python), and even the book is constructed the way that it explains both Python 2 and 3. It was deemed useful by the author for years to come.

    Therefore, I think the way you would approach the improvements sounds reasonable.

    Cheers, L.

    Reply
  9. TyRoXx
    02/10/2014

    grey on grey; didn’t read

    Reply
  10. Kieran
    02/10/2014

    Take a look at http://hacklang.org/ – when used in strict mode it’s exactly what you’re proposing (with a start tag of <?hh, typing, magic arrays removed etc)

    Reply
  11. Jesse Donat
    02/10/2014

    The problem with making all strings handled as Unicode is its slow and often error prone as there is legitimately no good way to detect the encoding of most 8 bit character sets.
    I mean this was one of THE big reasons PHP6 got canned. Processing variable bit size characters in a meaningful fashion is a complicated and heavy operation, this coming from a guy that has to do it on a multi-terabyte dataset on the daily.

    I really think for all its mocking PHPs decision to stay basically encoding agnostic thus far is the right descision and that a string should remain just a stream of bytes with no magic. Magic is always bad and results should always be predictable.

    Reply
  12. Alex
    02/10/2014

    In terms of performance there are ways to combat that even If php itself it’s slow and I noticed that it’s not written in the article.
    The trending stuff in php right now are the php extensions that are close to C++ performance and the next big thing is phlacon (php extension framework) which will speed up a little.

    Even if PHP lacks some of the features there is plenty of room for improvement as you mentioned in the article plus you can do async PHP which is close in performance to node.js

    Reply
  13. Ivan
    02/10/2014

    Did you mean to say: “if you have a file named “0” in your directory”? File named ‘1’ is still true, but ‘0’ will break the loop…

    Reply
  14. Steve
    02/10/2014

    Programming languages are like non profits. They need to define themselves and have a clear vision. PHP needs to re-define itself. What is the new vision? 5.3 was a good start.

    From php.net
    “PHP is a popular general-purpose scripting language that is especially suited to web development.

    Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world.”

    Consider Hack Lang http://hacklang.org/. Perhaps it’s PHP’s brightest light.
    FB has put considerable effort to fork PHP and developer their own language + interpreter for good reason. Change is likely too slow or wouldn’t be made in PHP itself.

    What your describing directly points to Hack Lang. Even their syntax is:
    <?hh

    We should all take a look at Hack Lang (myself included). It could be what PHP 7 will be in a few years but is ready and available to use today.

    Reply
  15. Nuno Brito
    02/10/2014

    Yep. I stopped using PHP as the code grew big on my projects. Was suddenly too difficult to find the right variables or to see what wrong without having to reload the browser.

    Then I started using Java. It comes with the features you mention (no integer issues, static typing, optimized API for just about everything) . What I really enjoy are the available IDEs (I use Netbeans). It’s not a sexy programming option such as ruby but gets things done.

    btw. Java is plagued with bloated frameworks that give it a bad reputation. The language and platform without the weight of nonsense frameworks is quite a different animal.

    Reply
    • Jermaine
      03/10/2014

      Wait a second, why would you be using the browser to debug your code in the first instance?

      Reply
  16. Christian Walde
    02/10/2014

    As a fellow german i ask you to consider engineering over design and to have a read through this: http://contrastrebellion.com

    Reply
  17. Derek Martin
    02/10/2014

    Check out HHVM and Hack Lang for PHP. Both are production ready and help address some of your concerns.

    Reply
  18. John Naglick
    02/10/2014

    Every argument about why PHP is okay can be reduced to:

    0) An opening statement about how PHP is bad but we’ve decided to use it because…
    1) It’s everywhere
    2) It’s easy for novices to use
    3) A statement about how the only reason people dislike PHP is because “It’s not cool.”

    Which, if you think about it, can be restated as:

    “Lets disregard the widely-agreed upon consensus by people who know what they’re talking about and willingy use a language we know is terrible because it’s convenient and we can get people who have never programmed before to write our application”

    Have fun!

    Reply
  19. Warbo
    02/10/2014

    I agree with your points, but picking this line as an example of the *language’s* problems is a bit of a straw man:

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

    Code like this smells terribly.

    First of all it uses “==”. That operator should trigger a deprecated warning, since it’s never appropriate. Even if you want the coercion, it’s better to write it explicitly with things like (int) or intval().

    Next, it’s using “== true”, which is completely redundant since the “while” will interpret the value as a boolean anyway.

    Next, it’s performing assignment inside a condition, which is generally frowned upon. There’s potential to confuse “=” with “==” or “===”, it’s using a statement in the place of an expression and it performs side-effects (setting the $filename value).

    After all that, it’s just duplicating existing functionality anyway: you could just say $files = scandir($dh).

    Reply
  20. JPHP
    02/10/2014

    Can you clarify your comment about “a proper API that can be used to filter all incoming data” in relation to ext/filter? This extension has been enabled by default in PHP for nearly 8 years so I assume you’re familiar with it.

    Reply
  21. Sam
    02/10/2014

    PHP isn’t unpopular, it’s bad. When it was designed it was never intended to be used by actual software devs. It isn’t a good language. It isn’t a good way to make software. You are making a mistake.

    http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

    Reply
  22. Stefan
    02/10/2014

    Please correct your blog post. Perl 6 _is_ compatible with Perl 5. Migration can be done smoothely. One can use Perl 5 modules in Perl 6 and vice versa. One can even mix Perl 5 and Perl 6 code in the same file.

    Reply
  23. Ivan Čukić
    02/10/2014

    For me, the sad part about the whole issue is that the only benefit PHP has nowadays is that it is omnipresent. If the web server providers were as agile as they should be (I still know of a few php3 installations around), we would not be in this mess.

    We now have quite a few more modern (and less modern, but more popular 🙂 ) languages for web development, but they need (1) easier deployment and (2) better server administrators.

    As for a php successor, I agree that the best way would be to provide the nice transition mechanism like you have proposed, I’m just not optimistic enough to hold my breath.

    A fun approach, though, would be to create a php-based compiler for a proper language, and use php only to bootstrap the other one. (yes, I’m quite insane 🙂 )

    Cheers,
    Ivan

    Reply
  24. David Rasch
    02/10/2014

    presumably you’ve read about http://hacklang.org/ that addresses a few of these points. Namely it adds static typing and helps with some security problems via XHP.

    Reply
  25. Debjit
    02/10/2014

    Although your ideas for PHP improvement are great, but they all point towards one thing – a new PHP Based Framework and not PHP itself. The truth is there already exist many great PHP based frameworks as of now like Laravel, Codeigniter and WordPress

    Reply
  26. Craig
    02/10/2014

    PHP is the reason I won’t even consider using ownCloud. The language and it’s maintainers are beyond farcical.

    Reply
  27. Bob
    02/10/2014

    > ownCloud is one of the biggest open source project written in PHP if you look into the latest statistics.

    What are these statistics?

    Reply
  28. Keith Lu
    02/10/2014

    Hi, there are some spelling mistake. Near the “PHP 6 or 7”, the words should be “would”, “safe_mode”

    Reply
  29. justanr
    02/10/2014

    Python 2.8? Did you mean 3.x? To my knowledge Guido has said there will be no new versions of Python 2.

    Reply
  30. Peter
    02/10/2014

    >Guess what this following code does if you have a file named “1” in your directory
    >while ( ($filename = readdir($dh)) == true) $files[] = $filename;

    Pretty sure you mean a file called “0” since that would falsely terminate the loop. A file called “1” wouldn’t behave abnormally.

    Reply
    • Frank Karlitschek
      04/10/2014

      Ups. Fixed. Another great example why magic casting is not always a good idea.

      Reply
  31. Karlitschek: A possible future for PHP | Linux-Support.com
    02/10/2014

    […] his blog, ownCloud founder Frank Karlitschek ponders the future of PHP. He doesn’t regret choosing PHP for ownCloud, but does note that the […]

    Reply
  32. Marc Delisle
    02/10/2014

    Frank,
    did you try participating in https://wiki.php.net/rfc ? This is the place where PHP’s future happens.

    Reply
    • Craig
      03/10/2014

      Haha, PHP’s future is in the garbage bin of technological mishaps. You don’t need a proposals system to arrive at that desitination — nor can one prevent it.

      Reply
    • Frank Karlitschek
      04/10/2014

      Not yet. But perhaps I should 🙂

      Reply
  33. PHP, where do you go? | yet another draggy weblog
    02/10/2014

    […] to Python. Therefore I am appriciating the hackernews link from today: Frank Karlitschek wrote a very good post on his side concerning the pros and cons of PHP, have a look at it. I like the listings for […]

    Reply
  34. pratfall
    02/10/2014

    Does OwnCloud have any stats or metrics on what sort of systems the community version is deployed on? If it’s all sitting on people’s QNAP and Synology NAS boxes, for example, then, yeah, it becomes really hard to move the underlying technology. If a big chunk of the deploys are via OpenShift Quckstarts, where the user just clicked a couple buttons and has no idea what happened behind the scenes, then the underlying technology matters a lot less, and more risks could be taken with a port.

    Reply
  35. Stephen Tanner
    02/10/2014

    CamelCase – aVariable, MyClass, myMethod
    snake_case – a_variable, My_Class, my_method
    kebab-case – a-variable, My-Class, my-method

    Reply
  36. Frank Karlitschek
    03/10/2014

    @Ivan: Thanks. Fixed. Great example of the dynamic casting nightmare 😉

    Reply
  37. Frank Karlitschek
    03/10/2014

    @Marc Delisle I haven´t participated in that yet. Thanks for the hint.

    Reply
  38. Frank Karlitschek
    03/10/2014

    Thanks for all the hints about Hack. I´m aware of that and I even covered it in the blog post. I don´t think it is a valid alternative as long as it is not blessed by the bigger PHP community/project.
    Marco wrote a great blog post about this: http://www.marco.org/2014/03/21/hack

    Reply
  39. Bob
    03/10/2014

    Loved the article Frank! I agree with your summations of PHP. I’ve been developing in it for a decade now and I can understand and agree with all of your points.

    I actually recently started moving to Google’s Go language – which is one of those ‘hip’ and popular languages at the moment. Despite the inflation of it’s abilities by bandwagoners, I can say (after using it for the past 6 months on a new FOSS project I’m doing) that it is very capable, very quick and very easy. I’m loving it.

    I was thinking about OwnCloud just yesterday and wondering what kind of improvements in speed and gains in resources you could obtain by switching to something more nimble like golang.

    Keep up the great work! My wife and I love OwnCloud.

    Reply
  40. Victor
    03/10/2014

    I guess you haven’t heard of facebooks hack language as a successor to php? Their runtime is php compatible mostly, you can even run WordPress on it. Then you can choose to implement more and more features of hack. Like static typing etc. and slowly bring your code base up to new standards. Seems like everything you’re looking for is there. Is there a reason you haven’t mentioned it? Or is it possible you’ve never heard of it?

    Reply
  41. Frank Karlitschek
    03/10/2014

    @Victor: I have heard of Hack. Please read the text again 🙂

    Reply
  42. Sébastien
    03/10/2014

    Python migration is.smooth. slow but smooth. Quite a good.example.to.follow.

    Reply
  43. Richard
    03/10/2014

    There was a proposal for PHP to have static typing somewhere already, in a backward compatible manner. Here’s my list of things to fix:

    1. References are declared in the function and NOT by the caller. This is a nightmare for readability: you never know by reading the code whether the function is going to copy your args or use them in place. If a function works by reference, then both the function declaration, and the function-call should have the “&” prefix; the compiler should detect mismatches.

    2. Function redefinition is not supported (unlike most other languages). Worse, if you include a function definition twice, even if you are “re” defining it to exactly the same thing, the compiler will exit. It should at least be prepared to ignore the duplicate definition. [I filed an enhancement-request on this but it got wontfixed].

    3. Python has a couple of excellent features, which PHP shoud

    by ref
    func redec
    tuples
    utf strings

    Reply
  44. Richard
    03/10/2014

    Your comment is awaiting moderation.

    There was a proposal for PHP to have static typing somewhere already, in a backward compatible manner. Here’s my list of things to fix:

    1. References are declared in the function and NOT by the caller. This is a nightmare for readability: you never know by reading the code whether the function is going to copy your args or use them in place. If a function works by reference, then both the function declaration, and the function-call should have the “&” prefix; the compiler should detect mismatches.

    2. Function redefinition is not supported (unlike most other languages). Worse, if you include a function definition twice, even if you are “re” defining it to exactly the same thing, the compiler will exit. It should at least be prepared to ignore the duplicate definition. [I filed an enhancement-request on this but it got wontfixed].

    3. Python has a couple of excellent features, which PHP should emulate:
    namely, tuples (eg a function returns a tuple, very useful for expressive code), and named arguments to functions: $x = f ( a = “b” , c = “d”) .

    4. I’m not sure how important UTF8 strings are, because, utf8 works in a very backward compatible manner to ascii in most cases.

    Reply
  45. markc
    03/10/2014

    A general move towards sane improvements could be achieved if the PHP core devs put effort into an official set of code sanitisation and conversion tools for each version update.

    Something along the lines of the various pretty printer packages but on a deeper opcode level where the code is party interpreted and then re-printed with all the new semantics. As Frank has noted, other language jumps have failed because massive changes require massive rewrites for large projects… well, do whatever it takes to autoconvert ANY project to be inline with the latest PHP version. 90% of all old PHP code could be eliminated in one year if the people that know PHP best also wrote the very tools needed to convert all that old code which would then allow hosting providers to upgrade to the latest PHP version.

    Reply
  46. Untrusted
    03/10/2014

    “So I don´t understand the religious discussions why tool x is always better than technology y.”

    This is the problem with the PHP community. Good developers explain their issues with PHP in lengthy, reasoned articles, with actual problems of the platform, the language, etc. (like the famous “a fractal of bad design”). And the apologists dismiss it as ” religious “. I palmfaced when I saw Php chosen for ownCloud, and articles like this only confirm my lack of trust on its community.

    Reply
    • Frank Karlitschek
      04/10/2014

      So why do you think that a lot of big software projects are written in PHP?
      Some reasons are even included in the article. 🙂

      Reply
  47. Alex_PK
    04/10/2014

    The whole feeling I get from this article is “I would like to use python but nobody uses it so I am forced to use PHP”.

    Ask yourself why nobody is using python. 😛

    Jokes aside, most of what you write about PHP is wrong.
    See my other answer regarding your while true loop (TL;DR: you wrote it wrong, it’s not a language fault)

    Input validation is covered by most frameworks, and no language provides it in the core. All of them use a framework to do this kind of stuff (and most of the also to give you access to GET and POST variables).

    You can use UTF8 strings since PHP3, nothing stops you. You just need to remember to use mb_*() instead of the “Latin1 string functions” to manage them.
    The real problem with UTF8 (that NO LANGUAGE solved) is in sorting. Because it’s different for every country in the world.

    Strict typing? One of PHP’s best features is in NOT HAVING strict typing.
    You need type hinting? Wrap your base types in objects (like in Java) and use type hinting:

    class Int {
    private $v;
    public __construct($i) { $this->v = intval($i); }

    }

    function manageInt(Int $i) { … }

    I know it’s not as easy (you can’t override operators). I just prefer the flexibility of not having type constraints to the burden of a couple of checks here and there.

    safe_mode has been removed years ago. open_basedir is a security guard for shared hosting. If it’s in place it should be for a good reason: not access other user’s files.

    32/64bit: just use bcmath if you are not sure you can manage a number that fits in 32bit, or require 64bit.

    You can provide a docker-ized or a vagrant-ized version of ownCloud and distribute whatever php.ini file you prefer.

    I can agree on some of what you say. I also suggest everybody to use PDO, but I know some features are only available through dedicated drivers, so, for example, mysqli could be useful in certain situations.
    I also agree that some php.ini directives should be removed, but they ARE removing them.

    They are just careful not to break backward compatibility too much.

    Look at what happened to python with 3.0 and its backward compatibility break. 6 years and still nobody uses it (they are starting now to port libraries…)

    TL;DR: use PHP as PHP, not as Python or Java or Go or Javapscript. Accept its syntax, don’t try to adapt other languages’s syntax to it. Your software will be much better, and you will sleep better.

    Reply
    • Frank Karlitschek
      04/10/2014

      Please read the article again. 🙂

      – Input validation
      Sure. Some frameworks cover input validation. But as written in the article this belongs into the language runtime and not into a framework where people can work around it.

      – Obviously UTF8 is supported. But the point is that the two modes (non utf8 and utf8) should be killed and only utf8 should be used. Dealing with this option is the reason for a lot of errors.

      – 32bit/64bit
      Obviously people can work around this problem with bcmath and other ways. But the point here is that this is error prone and should be simplified.

      – Backward compatibility.
      Please read the article again. This is exactly the point. 🙂

      Reply
  48. slimpo
    08/10/2014

    Re static typing, PHP already has optional static typing with the addition of the SplType extension. It works exactly like you stated, but declaring the type uses existing syntax. E.g.: $i = new SplInt(7);

    It hasn’t caught on, however.

    Reply
  49. ownCloud development for the first two weeks of September | ownCloud.org
    08/10/2014

    […] a major concern for ownCloud founder and project lead Frank Karlitschek, as he also mentioned in his recent blog about the future of PHP. PHP is the language ownCloud is predominantly written in, and the health of its ecosystem has a […]

    Reply
  50. Olivier
    11/10/2014

    I agree that some features should be deprecated faster. Since ext/filter is in core, kill the GET/POST arrays, etc.

    I don’t agree with getting rid of open_basedir. It’s useful in a shared hosting situation, which seems to be one of the segment you’re targeting.

    I also don’t agree with getting rid of the compilation and runtime options. That’s one thing which makes PHP great. One can configure a special version of PHP just for owncloud and get NGINX or Apache to use it via PHP-FPM.
    I actually think that you should do quite the opposite and keep recommending extensions and apps to install which can improve the quality of the software. OC is so much better with Imagemagick and Libreoffice support. You also have mod_security rules, add a recommendation about how to configure Suhosin, etc.
    There are lots of great PEAR and PECL extensions, use them to build the best Owncloud there can be. It’s the role of sysadmins to configure their environment properly to support the best web apps; it’s not in your best interest to try and be compatible with most of the cheap hosts out there.

    Reply

Leave a Reply