Being "tied" to Facebook is the best thing that can happen to PHP. I stopped taking PHP core devs seriously since the PHP6 fiasco.
The "PHP6 fiasco"? A major featured release was too much, and had to be scoped down. Since then most stuff has been released as 5.4, 5.5 etc.
Did it break anybody's code? No. Did it divided the community? No. Did it halted PHP development? No. At worst, it make some prematurely released PHP6 books obsolete. Big fucking deal.
Compared to Perl 6 (still MIA for actual production development) and Python 3 (only 10% adoption or less after 5 years for an update that doesn't even offer that much), I'll take the PHP6 fiasco anytime.
At some point , every big open source project team must make tough choices to make the project "future proof". Python team did it, Ruby is doing it,NodeJS will to be compliant with ES6 modules.
Python 6 did it badly, Ruby didn't do much, and NodeJS will have the ES6 modules "update" happen automatically by virtue of them being based on V8.
Not sure about PHP6, but previous versions did - in unnecessary ways. Like "deprecated" warnings you couldn't really turn off, "safe mode" which let administrators decide which functions developers needed,...
But all in all PHP is still... quite OK language. We've seen better and we've seen many worse. It has lots of weird features (I would call them bugs), but it is useable once you learn to live with them.
Oh, and after many years I still HATE that dollar sign in front of each variable. Just hate it. :)
PHP 5.4 broke code. In more ways than documented in the help (where a list of breaking changes exists, but is incomplete). For good codebases that adhere closely to how good PHP code should be written it's probably not much of a problem, but the ancient and horrible code base I had to coax into working with 5.4 had a few places that broke.
I love how often the same people that are those complaining about 5.4 breaking code, throwing deprecated messages etc, and on the other hand still wailing about the weird artifacts and inconsistent function naming.
http://php.net/manual/en/migration54.incompatible.php lists very few removed functions and no renames. One case I had (which isn't even mentioned on that page) is htmlspecialchars assuming UTF-8 instead of ISO-8859-1 if no encoding parameter is given. I'm not sure that falls into »We're removing weird artifacts from the language«.
No those changes would be reserved for major releases.
But the removal of the likes of safe_mode, magic quotes and register_globals have been long overdue.
The only reason why they have been in there for so long is because it would break code.
Backwards compatibility has always been this cute silly idiom of PHP. Which has its good parts and bad parts. I'm glad that it has gotten more mature in that sense. 5.3+ have been a statement of such.
One case I had (which isn't even mentioned on that page) is htmlspecialchars assuming UTF-8 instead of ISO-8859-1 if no encoding parameter is given
I agree that encoding in PHP has been a consistent PITA, and making this move and not mentioning it, is not really helping.
But again I must say, It's actually a really great thing, and again long overdue.
I think Python 3 offers more than you think it does. I'm not going to try to convince you, but having used it steadily for the last month or so, I really think it does.
It does offer some things, but does it offer a "divide the community, halt the old version and still go nowhere much adoption-wise after 5 whole years" worth of things?
I started using Python when "Python 3000" (as 3 was called then) was just a pipe dream for the distant future. For all the trouble with the migration, it doesn't really offer much groundbreaking things.
Removal of GIL, a JIT, a few times or an order of magnitude faster, an integrated new async model etc would have been great. UTF-8 and a few tricks that could just as easily be added in 2.8? Not so much.
The GIL and a JIT are low level implementation issues though, right? E.g., Python 3 can be implemented in PyPy (and it looks like that's in the works).
Most of the Python 3 changes are design and feature related, and it's a lot more than just "UTF-8 and a few tricks".
Comments
The "PHP6 fiasco"? A major featured release was too much, and had to be scoped down. Since then most stuff has been released as 5.4, 5.5 etc.
Did it break anybody's code? No. Did it divided the community? No. Did it halted PHP development? No. At worst, it make some prematurely released PHP6 books obsolete. Big fucking deal.
Compared to Perl 6 (still MIA for actual production development) and Python 3 (only 10% adoption or less after 5 years for an update that doesn't even offer that much), I'll take the PHP6 fiasco anytime.
Python 6 did it badly, Ruby didn't do much, and NodeJS will have the ES6 modules "update" happen automatically by virtue of them being based on V8.
Not sure about PHP6, but previous versions did - in unnecessary ways. Like "deprecated" warnings you couldn't really turn off, "safe mode" which let administrators decide which functions developers needed,...
But all in all PHP is still... quite OK language. We've seen better and we've seen many worse. It has lots of weird features (I would call them bugs), but it is useable once you learn to live with them.
Oh, and after many years I still HATE that dollar sign in front of each variable. Just hate it. :)
PHP 5.4 broke code. In more ways than documented in the help (where a list of breaking changes exists, but is incomplete). For good codebases that adhere closely to how good PHP code should be written it's probably not much of a problem, but the ancient and horrible code base I had to coax into working with 5.4 had a few places that broke.
I love how often the same people that are those complaining about 5.4 breaking code, throwing deprecated messages etc, and on the other hand still wailing about the weird artifacts and inconsistent function naming.
http://php.net/manual/en/migration54.incompatible.php lists very few removed functions and no renames. One case I had (which isn't even mentioned on that page) is htmlspecialchars assuming UTF-8 instead of ISO-8859-1 if no encoding parameter is given. I'm not sure that falls into »We're removing weird artifacts from the language«.
No those changes would be reserved for major releases. But the removal of the likes of safe_mode, magic quotes and register_globals have been long overdue. The only reason why they have been in there for so long is because it would break code. Backwards compatibility has always been this cute silly idiom of PHP. Which has its good parts and bad parts. I'm glad that it has gotten more mature in that sense. 5.3+ have been a statement of such.
I agree that encoding in PHP has been a consistent PITA, and making this move and not mentioning it, is not really helping. But again I must say, It's actually a really great thing, and again long overdue.
I think Python 3 offers more than you think it does. I'm not going to try to convince you, but having used it steadily for the last month or so, I really think it does.
It does offer some things, but does it offer a "divide the community, halt the old version and still go nowhere much adoption-wise after 5 whole years" worth of things?
I started using Python when "Python 3000" (as 3 was called then) was just a pipe dream for the distant future. For all the trouble with the migration, it doesn't really offer much groundbreaking things.
Removal of GIL, a JIT, a few times or an order of magnitude faster, an integrated new async model etc would have been great. UTF-8 and a few tricks that could just as easily be added in 2.8? Not so much.
The GIL and a JIT are low level implementation issues though, right? E.g., Python 3 can be implemented in PyPy (and it looks like that's in the works).
Most of the Python 3 changes are design and feature related, and it's a lot more than just "UTF-8 and a few tricks".
For example, Python 3.4 is adding asyncio (http://www.python.org/dev/peps/pep-3156/).
And if you look at the _What's New In Python 3.x pages_, there's a ton of new stuff.
edit: forgot a word
I am starting to hope for a PyPy 2.8 or a PyPy 3000 that removes the GIL. Will have to wait and see how STM plays out.
I thought the perl 6 implementation was actually complete.
When an implementation is complete in the forest, and nobody cares and even fewer use it for production code, is it complete?
It isn't.
Ouch. Sorry to hear it. But good to hear you weigh in.