| If I'm a least-common-denominator web developer and I copy and paste some PHP code into a project from a google search, and I copy and paste some Ruby code of similar origin, what are the odds that each has a inobvious flaw? Or much worse what are the odds that if I'm an average developer and am picking a random feature from each language's standard library, making care to read the docs before using it in my application that I've still introduced a bug? (Consider that maybe I'm dealing with things that were considered strange and new when most of PHP is still from - like character encodings - particularly character encodings that differ from the system I'm running in). Most languages can be CGI-style executed by an httpd with shared-nothing, but can also start up and be a long-lived stateful daemon. I don't have to decide between putting a square peg in a round hole or throwing my code away to learn something entirely new if I realize I need the latter part way through a project. PHP comes with a excessively large (but strangely CGI/HTTP/HTML/SQL-obsessed) standard library littered with footguns, and for most of its life has not had a common pattern for reusable modules, and has not had a good bundler for shipping reusable modules or making working with C extensions easy - and as such few people bother reimplementing functionality from core outside of what's been provided there (which is all set in hard clay), and when they are forced to tend to do so in (plain-ole-interpreted) PHP and don't generally package it up for reuse outside their own projects - a practice much more common outside PHP-land. Case in point (goddamn strlen, even): https://api.drupal.org/api/drupal/includes%21unicode.inc/fun... Some of that is changing in recent history (as in well after other languages figured these problems out) with PSR (design for reuse) and Composer (bundler) but it's slow moving and the latter still won't compile C extensions yet: https://github.com/composer/composer/pull/498 Plenty of this could be solved in PHP, some of it already is if you have the luxury to work with a tiny subset of PHP projects, but the practice in PHP seems to still mostly be to have it piss in your face and believe that it's raining. People are in a rut of tradition or simply don't expect their tools or libraries to be good - and I've spent the last 6 years working with PHP (several products, several teams) and wondering where I can get some of the Koolaid that my colleagues are drinking. |