[spacemanmatt]

I espoused this sort of rhetoric until I worked at a PHP shop. Every other discussion was about problems posed by the shortcomings of the language, crossed with mistakes made by past staff. It's so easy to make assumptions about "good actors" and "reasonable developers" that just fly out the window with a team that picks PHP and/or doesn't know much else.

[mgkimsal]

I've worked at PHP shops - working on a PHP project for a consultancy right now - and there's 0 issues about 'shortcomings of the language'.

"past mistakes" are almost inevitable problems - I've been on both sides of this - creating things which likely caused someone else problems (learning to be better at tests and docs) - and inheriting problems created by someone see ( learning to demand better tests and docs from others when possible).

"past mistakes" have little to do with the language. Recently worked with a large Java codebase spanning back more than a decade. There's plenty of mistakes that have been made. And... there's plenty of 'language shortcomings' around Java too (go back to Java from 15 years ago, lots of shortcomings).

I was on a team that picked node for a project; the whole thing failed. Should I blame it on the language, or the people who made bad choices?

Perhaps the issue is mostly around people/teams that either aren't very good or more to the point don't have a structure in place to guide them and help them get better.

[indymike]

As I read this I'm upgrading an old Python 2.4 app to 3.8. It isn't just PHP.

[RedShift1]

Can you elaborate on the failed node project?

[mgkimsal]

Probably not much of interest. Small team of... 4-6 had mix of experience with php, java and .net (min 8-10 years of each, fwir). Someone wanted to learn node (of course... always the best reason to choose a star), and pushed that on others. I gave up fighting that. Then we needed to "micro service" the node code because... well... you know... we have to be on AWS and lambda because... scale. Funnily enough, 'testing' and 'testability' never seemed to enter in to the decision making equation.

[swivelmaster]

It depends on a lot of factors. I worked at a startup that used PHP and the initial code quality of Product A was godawful because some early hires didn't know how to properly structure their code. Over the next few years, as staff turned over, we were able to clean it up considerably, add a lot of good OO practices, and get to a point where new developers who didn't even have PHP experience could be very productive very quickly.

When we started a Product B about nine months into my time there, the new team wrote new, well-designed code from scratch, and was also very productive very quickly.

PHP lets you easily shoot yourself in the foot, but it also gives you all the tools you need to leave your feet in very good condition, and it's not difficult to do that either.

[phendrenad2]

That's true, I've made amazing things with PHP, but as soon as you throw some more people on the project, especially people who pine for their JS or Ruby and don't want to accept the PHP way of doing things, you get a shitshow of epic proportions.