I sometimes ponder what I'd fix, given the chance, about PHP:
* Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT.
* Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes of functions, too.
* Tighten equivalence requirements, == should work like ===.
* Etc.
But I always realize I'd just end up with Ruby or Python, both of which already exist and have fantastic ecosystems. Oh well.
Make the "stdout == response body" an explicit option
Why? It's a primary differentiating factor for PHP, and one of the cornerstones of its popularity. Given that it powers a non-trivial percentage of the web, from single page "hello world" sites up to multi billion dollar ecommerce sites, I'd say 'fixing' that one aspect is not something that needs to be.
"== should work like ===". Why? If you want ===, use ===. But given that HTTP, the lingua franca of the web, is typeless, and PHP is targeting web developers, having a language that doesn't enforce types in all cases isn't all that bad.
1: "Explicit option" means it's still possible, but shouldn't better practices be encouraged? Anything to push developers away from interleaving logic and templates
2: PHP, however, has types. == is wildly unpredictable
1. Why add complexity when it isn't necessary? Inline output is one of the best features of PHP in that it makes it extremely easy to get started using it. If you want templates you can add them. Not everyone wants them.
2. PHP is dynamically typed, like many other languages, and so you just have to know what types something can be and how they behave together. Even in a statically typed language you need to know how type conversions work. That's what the documentation is for ( http://php.net/manual/en/language.operators.comparison.php ). It's not "wildly unpredictable", it's defined and deterministic.
Easy to get started, then what? I didn't learn how to structure big projects until I moved to better languages that encourage (through defaults) better practices.
Predictable !== well defined. If you have to look through a chart for equivalence, it's unpredictable to the programmer. But this is a theme for all of PHP, you can't deduct equivalence, function names and function arguments orders, you have to memorize or peruse the manual. Sure, it works, but it has drawbacks.
"I didn't learn how to structure big projects until I moved to better languages that encourage (through defaults) better practices."
Do you think that PHP is the only language where developers look to other practices in other language communities to learn different/new/better/changing practices? Every good developer is aware of patterns and structures in other languages/platforms - I dare say it's almost the definition of a good developer. I would not regard a Ruby developer who'd only ever done Rails projects as a 'good' developer, regardless of how clean/elegant the code seems.
The requirements for a huge (often overgeneralised) enterprise application are very different from a little script for personal or small-community use. There are far more of the latter than the former, and those wanting to "get started with web programming" are going to start out with that too.
PHP has been wildly successful precisely because it can fit in entirely small use cases, as well as big cases.
Someone who needs to create a dynamic footer with a "copyright $year" in it... has no need for MVC, routing, templates, version control, etc. They just don't. It's precisely because PHP has a default content-type output of 'text/html' that this sort of 'throwaway' functionality can be done with PHP and pretty much no other language. Not that other languages couldn't do this, but everyone seems to turn up their nose at this market. And yet... this is where the majority of the next generation of developers (and the current gen, and the one before) come from.
>And yet... this is where the majority of the next generation of developers (and the current gen, and the one before) come from.
To say nothing of the innumerable medium sized businesses that use these kind of "throw away" techniques to generate vast revenue. Companies that were profitable long before node or mongo entered the collective vernacular and will likely continue to be profitable long after they've faded from popularity.
perl/cgi was a thing for a few years, but even by the late 90s was losing ground to PHP. PHP's been gaining ground year on year for a decade. Will it remain in this position forever? Nope. Another several years? I think so.
It's far too entrenched in too many operations to be easily replaced. Perl didn't get that foothold, simply because there weren't as many developers or websites back then. Well... "simply" - there are myriad reasons why Perl didn't retain its early mindshare and install lead.
1. IMO, the bigger issue with response_body == stdout is that the default data output is unescaped. Take a look at Wordpress templates. The fact that the template framework is PHP doesn't really cause any issues. And WP is diligent about keeping the escaped data easily accessible, so calling <?php the_post(); ?> actually works fairly elegantly.
2. I wonder if reliance on == has ever caused any major security issues? I know there's some edge cases, but I can't remember a time == ever came back to bite me. (Yea, you can point to strpos(), but everyone knows that example and it's marked with a big red box on php.net.)
How is that a bad idea? IMHO much better by default to be outputting verbatim instead of silently changing the output. Escaping is something you should be conscious of, since you then have a better idea of where you need it and where you don't, and what type of escaping you need.
They tried to do escaping on the input by default with the magic quotes option; that didn't turn out well.
I think at this point simply removing critical, old bugs, unicode support and removing and/or restructuring the cruft of the standard library would be enough.
Unfortunately, the biggest hurdle at this point is reputation. No full or dot release will change that.
"Tighten equivalence requirements" But PHP is a great tool for working with the messy world of the web. Being able to type !$anyvariable is expressive, obvious and straight-forward. I don't care what type it is. Unless, I do; then I use ===
* Make the "stdout == response body" an explicit option, and make a rendering engine the default instead. Just sending all output is a senseless DEFAULT.
* Remove all the array_x functions and turn arrays into a class instead, and change the parameter order to be consistent across all the functions. A similar action could be done across many other classes of functions, too.
* Tighten equivalence requirements, == should work like ===.
* Etc.
But I always realize I'd just end up with Ruby or Python, both of which already exist and have fantastic ecosystems. Oh well.