Hacker News Reader

I couldn't agree more. Most of the features mentioned as possible changes like a constant DB API, removing superglobals, ignoring php.ini configuration, etc. are already possible and available in PHP right now alongside the outdated aforementioned APIs. It's all about how you decide to approach and code an application. For most applications those things are no longer issues and haven't been for many years due to libraries abstracting away and essentially "deprecating" (but without removal) such functionality. This allows old code to stay backward compatible while new code to be incredibly clean.

Many of the other changes the author mentions like static typing, new tags made me believe he hasn't really looked into Hack/HHVM except that he mentions it at the end. Still, while I think that is a great product with a lot of potential, the small incompatibilities that still exist and prevent current frameworks and libraries from running on it are the main deterrent to committing and switching to it. Still, as those incompatibilities get fixed, it becomes a more attractive platform.

In the rush for "cleaner" code with more "modern" APIs, a lot of programmers miss the much more important issue of backward compatibility and being able to run mature applications. I would much rather have a language and runtime that can run some of the most useful software out there (Wordpress, Drupal, Magento, Wikimedia) that may not have the cleanest looking code out there, than a pretty language that has few useful programs. This has always been PHP's strongpoint and in respect to server apps, nothing else is even in the same ballpark.

> I strongly doubt PHP is going to ever make any breaking changes anymore, short of ones needed to fix Heartbleed-intensity security bugs. The core team has shown how much awesomeness can be reached without making those breaking changes. Some holes will never be plugged, but you can't have it all.

I'm sorry to say that this is not an accurate portrayal of how PHP is to be developed in the future. There will be a new major version of PHP: so-called PHP 7 to avoid confusion with the defunct first attempt at a PHP 5 successor.[1] This new major version will contain a completely new engine[2] that is definitely not backwards-compatible with PHP 5 extensions (though it should be backwards-compatible with userland code). The new major version also opens the door for any userland-level breaking to the language; the first three of which are a change to integer semantics,[3] an AST,[4] and a uniform variable syntax.[5]

Instead, I'd characterize PHP 5.3-5.6 as more pragmatic than visionary: PHP 6's major backwards-incompatible feature was going to be full Unicode support, and when that didn't pan out, PHP 6 no longer had a raison d'être. Instead of holding onto a number of useful language features for a few more years until a new major backwards-incompatible change was developed (now the new parse engine), they backported them to PHP 5.

[1]: https://wiki.php.net/rfc/php6

[2]: https://wiki.php.net/rfc/phpng

[3]: https://wiki.php.net/rfc/integer_semantics

[4]: https://wiki.php.net/rfc/abstract_syntax_tree

[5]: https://wiki.php.net/rfc/uniform_variable_syntax

Why couldn't they just do what the article suggests: Quirks mode.

That's how Internet Explorer managed to move forward. The entire web was written for IE 6, and it seemed like progression would be impossible, so they just had everything render in an IE 6 compatible rendering engine unless the site told them it could handle something better (via DOCTYPE).

PHP could do the same thing. Everything renders in the current PHP rendering engine unless the *.PHP expressly tells the renderer "I'm modern!" and at that point the new renderer is utilised.

You could even have mixed old/new sites so that old libraries can be accessed via a modern PHP page. It might require some serious architecture work behinds the scenes but to get a brand spanking new PHP environment with backwards compatibility (when needed) would be a worthy goal.

This is what I'd prefer, similar to "use strict" like Perl and Javascript.

Quirks mode would create a lot more work for the maintainers that could be better used for advancing the language. If you really have an old codebase that cannot be altered for some reason, you could keep using an old version of PHP. I'd rather they kept 5.4 around forever as a long term support version than doubled the complexity of developing PHP as a language. The breaking changes and deprecations with each new version are relatively minor, if those cannot be made to your existing codebase, you also likely wouldn't develop anything new there and wouldn't need a quirks/strict mode.

If you really need to, you can run multiple different versions of PHP at the same time.

See also Perl's use v5.XX / use feature, Python's from __future__ and Javascrip's 'use strict'.

Very interesting observation. Perhaps the community's reluctance to change (with some of these large open-source projects) is the same kind of dynamic you get within large multi-national corporations where not only are people within those organizations reluctant to make large changes, but once you've reached a certain scale it's just plain difficult to make changes happen.

My hunch is change at web-scale (when you care about community adoption) can only happen when it's done in a thoughtful, incremental fashion.

> It's like Guido van Rossum realizing that nobody wants to migrate to Python 3, and instead making Python 2 awesomer again.

Source?

Consider reading that as:

> It's [as if] Guido van Rossum realiz[ed] that [...]

Hey thanks! English is not my native language. Did I say it wrong?