Agreed! PHP really needs a non-backwards compatible fork, something to go back and refactor all the built-in functions so they're consistently named and the arguments are consistently ordered, and with sensible defaults all around.
If the fork did nothing else, that would still be a huge leap forward.
If you want safety, add a nice upgrade path so people can actually start using it easily on their existing codebases.
Tag the old API as potentially dangerous/unsafe/deprecated/ugly and warn (or error out if you can opt into a strict mode per-file) so people can upgrade incrementally without waiting for all their dependencies to first (who won't because they have no upgraded users), and without breaking all their tests in one mega-commit.
Actually, one reason people still use PHP is backward-compatibility. You can take an old project, import it to the latest PHP, and it'll mostly work. Try doing that with node, Rails, Python, or Angular 1.0.
One big mistake Microsoft made was breaking compatibility with VB6 and VB.NET. What happens to all those people who spent years developing VB6 applications?
If you took PHP and refactored everything and cleaned up the bad bits, it'd be a new language and not PHP. You'd be starting over from scratch and competing with all the other hot and trendy languages fighting for users.
Right, as if Python 3 is a hostile fork or something. Nope. The pushback against Python 3 boils right down to laziness on the part of library authors, and the 2.x people serve as a kind of echo chamber of conspiracy theory about what's simply an iteration.
That's kind of my point: If a non-hostile, non-forked, major version upgrade to an established language like Python encounters pushback from library maintainers and the community, what chance is there that a hostile fork to PHP will gather support from a critical mass of maintainers and community?
I honestly think a better way would be to write a library that acts as a wrapper/translation layer to the non-intuitive commands that exist in PHP (thinking about it, I'm sure one probably already exists).
I hope this site, and others, serve to convince the community that Node isn't going to work, and to move forward with iojs instead. Even if the Node project fixed everything, I would still prefer iojs.
I agree with the grandparent post. Joyent has been so flippant, and specifically when Bryan Cantrill made that post, I just totally lost all respect for Joyent. I spent the winter writing Go, so had lost touch with node-forward, and came back to the pleasant surprise of io.js v1.0.x. I think at this point, it would be a step backwards (and a mistake) to give Joyent even a meter of ground that's been gained with the io.js fork.