On Backwards Compatibility and not Being Evil

This is a repost of an email I sent to PHP internals as a reply to:

And since you're targetting[sic] the next major release, BC isn't an issue.

This sort of blanket statements that "Backwards Compatibility is not an issue" with a new major version is extremely unwarranted. Extreme care should be taken when deciding to break Backwards Compatibility. It should not be "oh we have a major new version so we can break all the things"™.

There are two main types of breaking Backwards Compatibility:

  1. The obvious case where running things trough php -l instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple "default" cases, it's a fricking bug fix too).

  2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the "Uniform Variable Syntax", that I already wrote about, the current discussion on "Binary String Comparison", and now changing the behaviour on << and >> in a subtle way. These changes are not okay, because they are nearly impossible to test for.

    Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the $ in front of variables to £ is a better change, as it's immediately apparent that stuff changed. And you can't get away with "But Symfony and ZendFramework don't use this" either, as there is so much code out there

As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science "purity" reasons to "make things better" have little to no meaning for PHP, as it's clearly not designed in the first place.

Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding << and >> is not one of those, and subtle changes to what syntax means is certainly not one of them.

Don't be Evil

Shortlink

This article has a short URL available: http://drck.me/onbc-b2g

Comments

Also Mund that breaking BC gives messages to two kinds oft users.

Existing users are being told "migration is work, better stay on the old one, or maybe migrate to a different platform"

For users evaluating the platform it tells "you can't rely on your stuff working for the next years, better go somewhere else to make sure your investment isn't in a dead end"

As C++ founder Bjarne Stroustrup says "Compatibility is a feature"

On the other hand, comfort in programming matters too. These days web developers tend to have experience on multiple platforms, and they compare them against each other. If PHP due to its lack of design and weirdness is less comfortable to use than other platforms, this will over time cause a brain drain, especially at the most senior level where the people who make the frameworks and libraries are situated.

That's why you have to be willing to make subtle changes if they increase developer comfort, even if they cause a brief amount of developer pain to migrate existing code. The fact that PHP wasn't designed should not prevent it from evolving towards a design. Purity matters if it reduces grief during programming.

As in all things, it is a balance.

" It should not be "oh we have a major new version so we can break all the things"™"

Yes it should, absolutely and completely.

Why? Because PHP must grow up. It is full of inconsistencies that hinder development and cause the weirdest of bugs. Speed is not the only reason why HACK is gaining popularity, the strict typing alone makes it a hundred times better than PHP.

I would love it if PHP7 would have a consistent syntax, with consistent error handling, predictable argument order, etc. And if that means breaking BC completely, then so be it, porting to PHP7 would be a breeze if all errors are reported by exceptions instead of "notice" messages in a log somewhere, that yuo enable or disable, preferably at runtime, based on the hostname of the server...

Vincent, true PHP has flaws - in the language design as well as in the standard library - and it would be nice if those were fixed. But: Fixing those destroys the whole Eco system. All libraries, IDEs tools have to be changed. But not only that - also all developers have to relearn things as you end up with a different language. See Perl 6 or Python 3 how such attempts fail. We can only do that in small steps. See removal of register_globals: That was obviously a thing we had to fix to have people write more secure code and a feature where there are work-arounds to migrate cod availablee but it took us 10 years (well 9 years and 10 month), from providing users better tools ($_GET/POST) and advising them to migrate, till we could finally remove that option. We're not living in the days anymore where Rasmus could ssh into every server and upgrade code on BC break but with massive investments by thousands of developers.

Yes, please break PHP! I'd love to have better arguments to sell a migration from PHP to a real programming language to my client and there wouldn't be a better argument than seeing PHP killing itself.

I agree 100% with Derick and disagree 100% with everybody else (except Johannes).

Breaking BC should ONLY be done when it is absolutely necessary, such as to eliminate security issues or to fix bugs, and NEVER on a whim such as "to make it more consistent" or "to conform to other languages" or, the worst of all, “because I think it ought to be done this way”.

There is absolutely no reason why code which was originally written for PHP4 over a decade ago should not run today in the latest version of PHP5. While it is permissible to enhance the language with new features, all the existing features should remain untouched and carry on working as before. In this way all the thousands of existing ISPs and millions of websites with their millions of developers will have (or should have) complete confidence that they can upgrade their copy of PHP without the fear that their previously working code will suddenly stop working. If you change the language so drastically that existing applications fail to work then you will have in fact created a different language, just like Perl 6 was different from Perl 5 and VB.NET was different from VB6.

As PHP is an open source language there is nothing stopping you from forking the language into something different, such as “ProperPHP” so that you can rewrite the whole syntax to conform to your ideas of “purity” and “perfection”. You could take this fork into any direction you desire, but when you ask the millions of existing developers to follow you, I can guarantee that their answer will be along the lines of “Fork Off!”

To those of you who say that PHP is a crap language that should be rewritten to “proper” standards I have this to say: If PHP is such crap then why do millions of people choose it as their development language? It is not forced on them, so they are free to choose whatever language they want. The fact that millions of people use PHP as their language of choice, and millions of websites have been written in PHP proves that it is not as crappy as you think. I have been programming for over 35 years and I have used a wide variety of 2nd, 3rd and 4th generation languages, and I can say quite categorically that every language has its share of good points as well as bad points, its fans and its detractors. If you don’t like PHP then all I can say is shut up and use a different language.

Sure, there are lots of examples of crap programs written in PHP, but that is down to the shortcomings of the developers, not the language itself. You cannot point to a bad PHP program and say "That PHP program is crap, therefore all PHP programs are crap" just as you cannot say "That rock is chalk, therefore all rocks are chalk". A crappy developer will always write crappy code irrespective of the language. There is nothing in PHP that prevents a competent developer from writing efficient and effective software, so in that respect it is an excellent language. If YOU cannot write effective programs in PHP then perhaps it is YOUR programming abilities which should be questioned.

@ Joeri Sebrechts – you said "you have to be willing to make subtle changes if they increase developer comfort, even if they cause a brief amount of developer pain to migrate existing code." I’m afraid that you couldn't be more wrong. Changing the language to please new developers at the expense of the millions of existing developers is simply not acceptable. If any new developer is uncomfortable with PHP then he/she should move on to a different language. Alienating thousands of existing developers just to please a single new developer would be one way of killing the language completely.

@ Vincent: you said "PHP must grow up. It is full of inconsistencies that hinder development and cause the weirdest of bugs." The inconsistencies have not hindered millions of programmers from developing millions of programs, and 99.99% of the bugs out there are caused by bad developers and not bugs in the language itself.

You also said "porting to PHP7 would be a breeze if all errors are reported by exceptions". Where do you get such ridiculous ideas? There is nothing wrong with PHP’s existing error handling mechanism, and forcing everyone to switch to exceptions will make you more enemies than friends. You are aware, of course, that exceptions are just one way of dealing with errors and not the only way?

@ Thomas Koch: you said "I'd love to have better arguments to sell a migration from PHP to a real programming language" which means that your definition of "programming language" is seriously flawed. PHP most definitely IS a programming language, just like COBOL, Perl, Java, Python and Ruby.

You also said: "there wouldn't be a better argument than seeing PHP killing itself." This is the only intelligent thing you said as it is quite obvious that making unnecessary changes to the language which causes existing code to break will have the effect of killing the language instead of improving it.

I won't waste Derick's time moderating a reply to what is essentially just a rant, but I do want to say this:

" and 99.99% of the bugs out there are caused by bad developers and not bugs in the language itself."

A language that requires a good programmer to make it work is itself worthless.

""You also said "porting to PHP7 would be a breeze if all errors are reported by exceptions". Where do you get such ridiculous ideas?"

There is plenty wrong with PHP's error handling, and the fact that there are more than one way to report an error is an example of that. In languages such as Java, C++ and Python I can put one big try/catch around any piece of code and I can be sure that I will catch any errors that the code generates. In PHP I can use a try/catch, but I also have to set error_reporting to maximum and write some errorhandler that can actually turn an error into a fatal error if I want to catch undefined etc. If I'm really lucky, I'll load a library that is written by some "expert" who sets error_reporting back to zero because he thought that was a neat idea, of who writes his own errorhandler so mine is skipped altogether.

Been there, cursed at that, blamed PHP for making it possible.

@ Vincent: "A language that requires a good programmer to make it work is itself worthless."

The language "works" as it is. It is not so bad that even competent programmers find it impossible to write effective software. By your definition, if a programmer can write a program in language X and that program has errors in it, then it is the fault of the language! Really?

I have been writing software with PHP since 2002, and I have absolutely NO difficulty in writing effective programs, and if I can do it then anyone can. If YOU can't, then perhaps the problem lies with you and not the language.

"There is plenty wrong with PHP's error handling, and the fact that there are more than one way to report an error is an example of that."

I repeat, I have found nothing wrong with PHP's error handling abilities as I have been using the set_error_handler() function to trap and deal with all errors, warnings and notices since 2002. The fact that PHP doesn't throw exceptions for everything by default is irrelevant. If you are incapable of dealing with errors which are not thrown as exceptions then it signifies a lack of flexibility on your part. Personally I don't like exceptions and avoid them like the plague simply because they are WORSE than PHP's native error handling abilities.

"I have been writing software with PHP since 2002"

Hmm... I've been doing it since 1999, and in other languages since somewhere in the late 80's, so what does that mean exactly?

" and I have absolutely NO difficulty in writing effective programs, and if I can do it then anyone can. If YOU can't, then perhaps the problem lies with you and not the language."

Personal attacks indicate a lack of proper arguments.

The point of programming languages is not just that you can write programs, they make writing programs easier, faster and the endresult reliable and predictable. PHP's loose typing, inconsistent arguments and error reporting just make it more difficult. Sure, you can work around all that but seems a waste of time to me. For example: If I write a method that expects an integer then I should not have to waste my time writing code that checks the content of the parameter to be an integer, especially if the language does allow that for classes.

"Personally I don't like exceptions and avoid them like the plague simply because they are WORSE than PHP's native error handling abilities."

I don't know a polite way to express how silly that statement is, so I'll just leave it alone, I'm not even going to ask you to explain :-)

Add Comment

Name:
Email:

Will not be posted. Please leave empty instead of filling in garbage though!
Comment:

Please follow the reStructured Text format. Do not use the comment form to report issues in software, use the relevant issue tracker. I will not answer them here.


All comments are moderated

Life Line