The phrase "shared nothing" springs to mind.<p>Years ago (1999?) one of the early PHP bloggers had written that PHP was good precisely because of 'shared nothing' architecture. There was no shared memory, no threads, etc to trip you up.<p>Years ago, and colleague bitched about PHP, and one of the issues was 'no thread support'. I went to pick him up for lunch one day, but he couldn't make it - 'debugging some threading issues' (in either java or c++ - can't remember which one). I... didn't quite bite my tongue, and, while I know 'different tools for different jobs' makes a lot of sense, I also know many people have made more work for themselves by explicitly avoiding even greenfield projects in PHP because... well.. because it's PHP.<p>Also, from what I gather, PHP will be getting real async support in a couple years, which may throw some of the 'ease of thinking' arguments out the window a bit.
I have been working on .Net c# this past 2 years, coming from PHP. The hardest thing for me was to remember to close my database connections. Of course when you don't close one connection, your app doesn't break, it simply consumes more memory. After a few hundred requests, your database fail and you have no clue what went wrong. (close your connections!)<p>In PHP, when your page is done processing, the process is killed and all the connections, file handles, or resources it had open will be closed.<p>The more I work with .Net, the more I get to appreciate the things in PHP I had taken for granted.<p>I wrote about this a year ago: <a href="https://idiallo.com/blog/php-fast-debug-time" rel="nofollow">https://idiallo.com/blog/php-fast-debug-time</a>
Presumably, this guy's never seen $_SESSION hell: enormous amounts of state stashed in a single super-global associative array that persists between sessions [1].<p>In addition to $_SESSION hell, lots of custom PHP applications end up with extremely complex and convoluted MySQL tables dedicated to storing what would typically be global application state.<p>Both of these can lead to difficult-to-debug performance issues, race conditions, and especially security vulnerabilities.<p>Global state is going to happen, so languages/libraries should provide mechanisms that make it easy to state and enforce strict invariants on reads and writes to global state.<p>[1] <a href="http://php.net/manual/en/reserved.variables.session.php" rel="nofollow">http://php.net/manual/en/reserved.variables.session.php</a>
Anything, in any language can be written to not share state, to reload everything on every request and to throw out after the response.<p>We're setting the bar pretty low for what's a good thing in a language here.
Yes PHP, that's how it all started with CGI. This provenance also dictates that PHP must be fast to load. I'm often surprised at how fast a PHP process will complete in comparison to Python.<p>Still, I remember having to cache initialization state in PHP because it took too long to build it on every request. That's when the model breaks down and you prefer a server with state.
Guilty admission time: I run thousands of distributed worker processes in PHP. Some of the processes run for months at a time and I've not encountered any issues nor memory leaks. I assume the others would too but they get replaced anytime we deploy, so the uptime is usually measured in days.
Developers just blame programming languages. As always.<p>As much as a programming language gets more popular, and more programmers write code with it, you see more "quick-and-dirty" solutions around.<p>As Java started to become even more popular cos of Android, I see more crappy code written in Java.<p>As much as Scala codes were clean when only early adapters would pick it, now I see more "quick-and-dirty" code because simply there are more codes out there.<p>The main problem is the majority of developers are not disciplined/experienced/responsible enough to keep their code organized and learn how to do it.<p>And that is just how it works with everything we do. Majority of people also don't keep their house/room/desk clean and organized.<p>As soon as any programming language hit the top 5 popular programming language, you have enough example to complain about it.
There are a lot of nice things in PHP. The bad parts are pretty well known.<p>As Bjarne Stroustrup said, there are only two kinds of languages: the ones people complain about and the ones nobody uses. Having invented C++, he should know.
> ... at the same time the single and the only huge factor which make poor PHP code written by junior developers manageable is this ...<p>One thing many people misunderstood is that "PHP are for newbies".<p>No, you need to have some serious knowledge on PHP to be able to navigate yourself away from all those pitfalls that language provided. For example, use ===, be careful with "0e123" etc.<p>All those pitfalls combine, is annoying enough to out weight most the good things that PHP also provide.
PHP being stateless is a good thing, as well as real classes, real interfaces and type hinting.<p>Sadly, PHP developers still use bad coding practices. For example, one of the popular PHP OOP frameworks, Symfony, makes things like HTTP Request or logged user a global variable by storing it in DI container. What about incapsulation and concern separation? The code breaks if you run it from CLI. PHP should not copy bad ideas like this from Ruby.
The good thing in PHP that I don't think enough people talk about is Laravel.<p>If you are starting a new PHP web app and you expect to grow beyond a toy project, I highly recommend starting by using the Laravel framework. Laravel provides so many useful things and it encourages good separation of concerns and code organization. But it is flexible enough to get out of your way if you need it to.
I find PHP better than I thought I would because it supports a style of programming that's very similar to Java, but the big problem is that PHP developers often tend to have more of a "quick-and-dirty" mindset and don't really appreciate that kind of code.