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.
They did not.
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.
They did not.
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.
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.
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
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. :)
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 don't necessarily blame the "old guard" - they've been around a long time and they've seen a lot of failed ideas - and it's been them who dealt with the cleanup and had to maintain those broken features long past the founders of those features had moved on.
This isn't a bad thing: PHP is rooted in many businesses both small and enterprise: it will be around for a long time. Projects like HHVM are going to ensure that.
However, I no longer think that PHP is going to "turn it around" and will ever be a model of innovation. It lost it's opportunity to do that.