[bowlofpetunias]

Methinks the argument that PHP encourages shitty programming has been effectively countered by the amount of crap legacy Ruby code that has appeared several years since Rails became "hip".

It should be quite obvious to anyone by now that when it comes to shitty programming, language is negligible factor once a language has hit the mainstream.

But I'm pretty sure 5 to 10 years from now someone manages to argue that Ruby is crap, Rails is to blame for encouraging a generation of developers to write bloated controllers full of spaghetti code, and that this attracts shitty programmers incapable of understanding software architecture.

[pgeorgi]

I already start arguing along these lines now - starting with the refusal to define even semi-stable interfaces across versions of a library.

Instead of relying on actual reusable building blocks, you're expected to build specific versions of ruby interpreter and libraries for every project.

Imagine having to cope with just ever so slightly different (but certainly incompatible) philips screws whenever you want to affix one physical thing to another.

[lotyrin]

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.