High Quality PHP

The difference is that PHP was not really designed for the type of use it gets. It began as one guy's hobby project and somehow snowballed to power some of the biggest sites on the internet without really having the backing necessary to support that position. PHP maintainers have been desperately attempting to backport the type of functionality that Serious Business people need, but it's never going to be as organized or clean as something that was conceived to serve that purpose.

If you care about code quality, choosing PHP already puts you at a disadvantage. It's not that people can't write adequate PHP code, or that people can't write ugly code in other languages. It's just that most other languages give you a pretty healthy head start over PHP when it comes to cohesion of organization, presence of important language features, etc.

[edit]It's since been fixed. That was an impressively quick response.[/edit]

All sorts of interesting things happening in this space, especially PHP-FPM and HHVM. The language design and code quality/organization capabilities may not yet be up to snuff with Python and Ruby, but the runtime options are as good or better.

I went to leave PHP this year, and didn't end up doing it, because of how much has changed lately. It's a good language, with awesome tooling know. I can write well-tested, easily readable, maintainable code using small composable libraries, and big frameworks when needed, without fighting against the dumb parts of the language. It makes me happy :)

phpBB and Drupal have their problems, but they both improved their code-base alot, moving from legacy PHP software to software that is much more maintainable. The road to "high quality software" is long, but throwing software out of the window instead of slowly improving it is not the right solution either.

Both projects have high numbers of unit-tests and can guarantee backwards compatibility and regression free releases in a much better way than most of the software out there in any company, written in any language.

The reason I picked PHP for a project years ago wasn't because it was easier for me to set up, but because it would be easier for users of my code to set up. If you're writing code to work on your servers that's a different thing altogether. Similarly I picked PHP for a later project simply because it was available and configured, whereas anything else would have had to go through approval and tech support.

For my personal stuff I use a shared server (dreamhost) which is pretty typical for low-end providers. PHP isn't merely easier, it's possible.

Now my professional stuff goes on dedicated servers, so that's great. But the problem with them is that when I want to tinker, I want something really simple and foolproof to work with. If I come back after not looking at a side project for several years, I'd like to not have to spend days figuring out the runtime setup.

We are getting close to a better world. I see a lot of pretty cheap/free and convenient options for hosting node and rails projects, but usually database access is yet another stumbling block.

You can easily write one with Rails over just a few months of maintenance. I hate, hate having to do a damned autopsy to trace all the @instance (read, global) variables copied and inserted into the objects that you never create yourself, -because Rails devs are apparently above having to endure the savagery of passing arguments to their methods- and having to grep every single function that gets automatically included from everywhere in the project into the namespace.

PHP does not automatically convert types unless you do something like this:

if( 33333333333333333333 == '33333333333333333334' )

But here the problem is the integer overflow not specifically the type conversions. You are going to get weird behaviour no matter what you do because you don't have enough bits to store that number.

If you want to use numbers this size then you are going to need some type other than the standard int.