Just today I got yet another email asking me why we do not rewrite PHP to get rid of all the cruft and past mistakes. These kinds of emails obviously have become more frequent since the namespace backslash decision. First up I wonder why people send such emails to me? After all I have only very rudimentary knowledge of C, let alone all the PHP specific infrastructure (macros etc.). So I am probably the person with the least ability to make something like that happen or even judge its feasibility among all of "PHP core" folks. But still since the question is often enough posed to me, I guess its more efficient if I reply to it in an easily linkable location. So the gist of my answer is: I would welcome a serious effort to rewrite PHP from scratch, but I do not think it should be done by PHP.net
Let me start with a disclaimer: Of course PHP is not without error. Far from it. Actually I have stated before that the willingness to screw up is one of the main reasons for PHP success in the light of the competition. PHP has evolved without much design. Of course looking back its now fairly easy to point out where the evolution went wrong. Some of that is fixable, some of it isn't. Still this is not stopped its success: PHP is huge and will remain so for years to come!
As a result a lot of people have bet their business on PHP. They have invested heavily in building up large code bases. More importantly a lot of people have bet their careers on PHP. So if we go an "reinvent" PHP from scratch, we would do these people a huge disservice. Even if these people would appreciate the rewrite as something they would have rather used, its too late for them. Too late for their current projects at any rate. I think its PHP.net's job to continue developing PHP to make sure it solves the "web problem" while ensuring a realistic upgrade path for its current users.
Now if some group of people comes along and takes everything that is good in PHP, fixes past mistakes then I say: More power to them! Give it a new name, rock the world and one day they might even supersede PHP more or less entirely. At which point there will likely be less and less developers working on PHP, as people become more interested in the new kid on the block. PHP will likely still have people looking after it, if only to fix security issues. And this is all good and this sort of thing is what makes OSS so successful.
That being said I would be mightily ticked off if I saw a group of people start something like without being sufficiently humble and serious at the same time. If you want to stand on the shoulder of giants you better not try to sabotage the giants while you are at it. I think a group of people that state and follow through such a rewrite would do best to work hand in hand with PHP.net. A lot of things that people suggest as the first things they would fix in a rewrite, are actually not as broken as these people believe. However to know this, one has to know the history of how we got to where we are today. In this way the Drizzle team did a lot of things right, though they do tend to bash the MySQL source a bit too mich imho. I think its a question of common courtesy to peers to not make fun of the code that is put out, state facts and remember that not everybody has the luxury to be able to take as much time as is necessary for every line of code.
great post! What you describe here is I think exemplary for all evolutionary software development.
Looking back and identifying what is wrong is useful, but not nearly as difficult as producing something right. Improving broken-ness, clearing out cruft, and refactoring are also easier when you don't have users (let alone customers) waiting for you.
I don't particularly think that PHP should be rewritten as a new language, per se. A language is identified by a variety of things, but to most people, it is identified by syntax, paradigm, et cetera.
While this is arguable, fixing PHP's mistakes would not really consist of changes that modify how people identify PHP as PHP. You wouldn't really change the syntax.
You would, however, create a universal order for $needle and $haystack arguments in functions. You would fix blatant object-orientation flaws. You'd fix the recursion efficiency. The speed issues? Not as slow as Ruby, but not even close to being on par with Python. Anyway, we digress....
Point being, it would not be to anyone's benefit to create a "good" PHP and a "poor" PHP, because you'd simply end up dividing the community over a language that is practically identical.
I say: Fix PHP and make it the next major release. The developers should take responsibility for their mistakes.
Though Dagfinn's article is good, I've always enjoyed pointing to Joel Spolsky's article Things You Should Never Do, which talks about the Netscape rewrite and how that decision doomed the product and is a wonderful lesson for all people contemplating a rewrite.
Agree with Nick - what only Php need is new major release with some syntax and model fixies sending wrong things (namespace syntax :)) to the deprecated hell.
The same thing happend to Php4 when moving to Php5 and is the only evolution way.
What I'm realy afraid of is the date of new major release - it seems there is no realistic roadmap present.
The changes necessary to allow us to use :: as the namespace separator would essentially mean every PHP app in the world would need to be adjusted. That is not what I call evolutionary, which is why we did not consider it as a viable option. Then again I doubt that creating a new PHP just to be able to fix this, along with needle haystack order is going to win people over. But I am sure people are able to compile a long list of things both syntax-wise, what functions to offer and even performance-wise that could start to become interesting. Even then it will be no trivial project and I hope that nobody confuses the community with a half hearted attempt.
Every software has its failures - and so PHP. Existing known failures have to be fixed. New failures will be made. That is Software Development.
There will be many enhancments and fixes in PHP 5.3 and PHP 6.0.
BUT. I think sometimes it would be better to have a bigger BC break to then have some more former waste cleaned-up. Perhaps a better release cycle and BC policy will solve such a problem?!
php is not bad language but... need some features assap:
-namespace support. Classes, Packages without NS is hell
-more control for modules including
-features that allow to unset and uninclude classes
-possibility to compile and execute scripts, code strings to bytecode and store/include compiled code anywhere without apc stuff, encoders, eval, create_func.
-open and clean well-documented API to PHP embedding system (like Perl, Python embedding API)
-more integration for linux package systems. Developers cant test new php without any install tricks. Configure and make install command is not enough