4 ms·
There is one other strength that PHP has which is not replicated by any other runtime on the web, with the partial exception of Perl: its execution model. PHP c
by Udo 11y ago
There is one other strength that PHP has which is not replicated by any other runtime on the web, with the partial exception of Perl: its execution model. PHP code is executed per-request only, as opposed to within the context of an already-running app server. This means your PHP app has no state beyond what you explicitly build into it during each request, and this makes reasoning about state and control flow very easy. I love how this makes debugging, optimizing, and scaling, much more natural.
This is the reason why PHP is still my go-to first choice when it comes to request-based server apps (and together with Node.js it's also a good option for continuously-running applications). For me, the sore points of PHP are its syntax, scoping behavior, and the awkwardly structured standard library - to the point where I occasionally look elsewhere, or consider building an alternative myself.
- icebraining 11y agoA few configuration lines, and you can run Python scripts just like PHP scripts, using mod_wsgi: https://ubuntuincident.wordpress.com/2012/05/06/use-python-like-php-in-public_html-with-wsgi/ https://ubuntuincident.wordpress.com/2012/05/06/use-python-l...
- Udo 11y agoOh, you can go that with most languages, not just Python. However, they're not designed for it. PHP comes with the FPM server and an opcode cache which makes this execution model performant in a way that was not possible before with CGI. With PHP, a lot of development effort went into making this work really well.
- icebraining 11y agoOpcode caching actually came late in PHP (Python had it built-in since at least version 1.4, from '96). I agree that Python has no FPM equivalent, though. There are FastCGI servers, but none that simply throws away all state between each request, AFAIK.
- jskulski 11y agoThis also leads to the rise of single tons and creating objects wherever you need them. It's hard to grok Dependency Injection when your objects live and die all the time. It makes reasoning about state easy because you don't have to consider it. In my experience (which involves several large and mature PHP codebases), that's not a good thing. You're right about the benefits, but the downsides are glaring too.
- Udo 11y agoI agree, and I see every day that PHP apps are not written with both these pitfalls and advantages in mind. Instead, most "foreign" PHP code I look at today is either made to look like it was designed for a Java app server or is so ineptly cobbled together that no apparent thoughts were invested into the structure at all. I blame both of these on the messaging and marketing coming out of Zend and the surrounding ecosystem, namely that PHP is supposed to be a language where big applications are constructed with convoluted EE-like class trees, and that PHP is supposed to be a beginner's language. Both of these constitute an outright failure to recognize where its strengths and weaknesses lie, in my opinion, by the same people who are maintaining the language.
- pmontra 11y agoAgreed, but as we're reasoning about a post of DHH, an idiomatic Rails application doesn't carry any state worth thinking about from a request to another one. Exceptions are tiny bits of information stored in cookies (usually nothing more than the id of current user) and the database. PHP does the same. The difference between PHP and application servers is that all its runtime environment is reloaded from scratch at every request. This is both a good and a bad thing.