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.
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.
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.
The needs aren't very exotic. You can use them any time you need to do multiprocessing, a common example is building a daemon to process a queue in parallel with multiple workers.
Also, the pcntl functions don't provide multithreading primitives, only multiprocessing (fork)
Edit, looks like there is also a pthreads extension
> The needs aren't very exotic [...] a common example is building a daemon
While "writing a daemon" is pretty common, I've never seen a daemon written in PHP (I'm sure they exist, I've just never seen one), so I would call that an exotic use-case :P
I had to maintain one, would not recommend it as a general pattern. Most of the problems might as easy have to do with the original author and his experience in writing such an application (and hence choice of PHP for this task). But this post also springs to mind: https://software-gunslinger.tumblr.com/post/47131406821/php-...
The reality is almost certainly far simpler. PHP started as a suite of tools for writing CGI pages [1], which have the same property mentioned. As with many things, that early design choice has followed through and led to continuing to execute PHP in similar ways as CGI did way back then.
You can write a server that will handle multiple requests in PHP, for example, using ReactPHP.
By the way, I don't like how they implemented promises and asynchronous file streams: they copied them from Node.JS and didn't implement proper error reporting (which Node did't have at the time too if I remember correctly). For example, if there is a promise that was rejected and the rejection is not handled, there will be no exception thrown. So the developer won't even know about an error, even if it is a syntax error. That's how poorly Javascript promises were designed. Now this is fixed in JS and unhandled rejection will produce a warning in the console but there are many other bad things about them.
It's funny you got downvoted for this (at the time I'm writing this), considering (based on your comment history) you're likely Rasmus Lerdorf, creator of PHP.
It's a perfectly valid and normal reaction. Regular viewer has no reason to suspect that this is anyone special speaking. That comment was indistinguishable from a random thought of a random person, so it was entirely reasonable to request a citation. "That's me, Rasmus" would be enough of a citation of course.
Indeed! That's what I was implying with "based on your comment history".
It required me being curious about why a random commenter would make such an authoritative (but not backed up) statement, remembering PHP's creator's name and making the connection that their username may be related to it, then reading his Wikipedia page and digging through his comment history to find a couple from 2015 (about UWaterloo) and then 2013 (about his age!) as supporting evidence!
I'd hesitate to say PHP has a "perfect sandbox". I certainly wouldn't run a script like `eval($_GET["foo"])`.
The only "perfect sandbox" I can think of for CGI programming is something like Unlambda (pure functional, except for monotonic reading of input and writing of output)
I do not think PHP had design decisions until ... much, much later than day one. I would cautiously say even PHP 4 is more than a bit haphazard and PHP 5.0 I definitely remember as an alpha quality release, 5.1 as beta and 5.2 as stable. Design, I think, started to appear with the later stalled PHP 6 attempt and so mainline 5.3. The first one I remember that can be called a conscious design decision was deferring $this support in closures to 5.4. Correlating with my memories is the first release to appear under the "Implemented" headline on https://wiki.php.net/rfc is 5.3 indeed.
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!)
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.
The more I work with .Net, the more I get to appreciate the things in PHP I had taken for granted.
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].
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.
Both of these can lead to difficult-to-debug performance issues, race conditions, and especially security vulnerabilities.
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.
Thats pretty much a bad practice well documented accross various php tutorials and books. But many php developers have no understanding of programming so they stash everything in that _SESSION superglobal or do other scary things.
Global state in general is bad practice well documented across tutorials and books about programming. Article's argument is that PHP avoids global state, but _SESSION hell and "MySQL table as global state" patterns demonstrate that programmers will always find a way to shoot themselves in the foot with global state :)
Also, IME even good PHP programmers suffer from the "MySQL-table-as-global-runtime-state" syndrome. And it's at least as bug-prone as storing global state in an ADT.
But practically speaking you can’t though. You’re not starting a new java process on every request because the overhead is too big, and you can’t fully reset the jvm state for every request.
PHP with fastcgi reliably and quickly resets the php process to freshly launched state after every request, and very few languages can manage that trick in a production context.
The article is about that it is FORCING you to do it. Erlang is designed to restart processes, because they also know it's very hard to keep state but don't leak memory or be in a good state for a long time. Every application server has an option to "restart after N number of requests" for the exact same reason.
Erlang is designed to restart processes when stuff goes wrong, because repairing is hard, and restarting is easy. This is different than PHP -- I hope my Erlang processes will have years of uptime, but I'm ok if they don't. My PHP requests have 30 seconds to live, and if they make it that long, they'll be systematically murdered (and, in some environments, the process they live in will be murdered after N requests, because even though PHP makes it hard to leak memory, developers rise to the challenge).
This property is definitely one of the things I love about PHP -- when the request is done, everything is thrown away. This encourages you to do the minimum amount of work to get your HTML (or whatever) out the door. I'd like to say it forces you, but it doesn't really -- I've seen plenty of 'lightweight frameworks' that mess around for 50 ms creating cathedrals of objects that just get thrown away on a hello world page; if you do the minimum amount of work, you can get pages out the door pretty quick. Layering and abstraction can solve a lot of things, but it can't solve wrong abstractions.
Sure, but I'd expect a paid web developer to be aware of the statelessness of http to begin with, and also to rely on testing to get any form of guarantee of any kind.
What I find ironic is that creating the illusion of state in php is an absolute pain without a framework, which again applies to most language/server combos I've tried.
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.
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.
>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.
I also had this problem, but fortunately, I could always buy my way out of the problem better hardware and maybe one afternoon of optimization.
I finally shut down the last of my PHP side projects because of pervasive security issues and a dwindling/dead community. I recently reinstalled one of those sites on a DO droplet. Getting the right versions of everything took an entire weekend, but I eventually succeeded. The droplet had way more RAM and a faster CPU than I had access to back in the day.
But holy hell those pages still loaded so slowly. I probably didn't notice at the time because internet connections were so much slower and waiting for an HTTP page with a few images to load was normal. But those load times would be absolutely unacceptable today.
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.
We've been doing it since 2011, though we saw significant improvements when we switched to 7.x. Memory and CPU usage dropped by ~50% at that time. We did have occasionally memory leaks back on 5.6 (usually around shared libraries like libxml) but haven't had any issues whatsoever since 7.
I didn't try too much daemonization around ~2005, though Schlossnagle's "Advanced PHP Programming" (2004) did have a whole chapter on daemonizing and the pcntl functions that made it possible.
Yes this is first thing I thought about as well. Since PHP commonly uses FastCGI, using CGI via fcgiwrap as in the case of a cgit deployment for example, is basically the same sort of model, in a more modern sense.
Many languages aren't really suitable for CGI, because of long startup times, leading users of those languages to not tending to have a clean slate on every request, unless they work for it. (Alternatively, if you don't want a clean slate on every PHP request, you have to work for that)
Yep, which is why Laravel [0], CakePHP [1], etc prefer to use a node app or separate server to handle WebSocket connections that then use an internal router to call PHP code.
In such cases, websockets generally aren't handled by the application itself, but by a server (e.g. the nginx in front of the app with plugins, or an extra server) that manages the connections, often provides "channels" and takes commands from the application.
Developers just blame programming languages. As always.
As much as a programming language gets more popular, and more programmers write code with it, you see more "quick-and-dirty" solutions around.
As Java started to become even more popular cos of Android, I see more crappy code written in Java.
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.
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.
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.
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.
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 ...
One thing many people misunderstood is that "PHP are for newbies".
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.
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.
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.
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 don't think Laravel is a good example. It uses a lot of global state and static method calls. It copied all bad things that were there in Ruby on Rails.
If you look at any code example here [1] you will see that global variables are used everywhere.
Using global variables in a careless fashion is a bad practice indeed.
But globals are not universally evil. Laravel uses globals very thoughtfully. Having used the Laravel framework for many years, I agree with many of the choices it has made.
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.
PHP supports almost any style of programming depending on the framework you choose. And that's sometimes a problem and as a consequence is 'that PHP developers often tend to have more of a "quick-and-dirty" mindset and don't really appreciate that kind of code'.
I tried Symfony, which I liked a lot, and I wrote code in a similar way as I would have for ASP.NET, which I thought seemed logical considering how similar they were. And then my colleagues complained that my code was too complicated and they didn't like all the type declarations when you could just easily return untyped arrays everywhere. I don't work in PHP anymore.
The same could be said of many scripting languages when frameworks have less influence. Had Rails not come along, and most Ruby apps were just files fronted by Rack, you'd see the same thing. ColdFusion has a reputation for being junk code, but that's because many apps are a bucket of files, and clean frameworks like ColdBox aren't nearly as dominant.
True enough. What I liked about PHP7 was that, optionally, you could have most of the rigor (and sophisticated IDE help) of non-scripting languages (although with a painful amount of boilerplate and some weird quirks).
Exactly. It's possible to write good PHP, but how much of that do you see in the wild?
PHP really baits people into making very fragile software. It's very hard to write good PHP. It's hard to write good C, too, so rather than frame it as an attack, realize that it's a long rope with which one can hang himself.
I think if you pick a sensible framework it's not especially hard to write sensible code (except it's hard to reason about the performance of PHP's associative arrays), but the older culture is hard to root out.
As a PHP programmer, among other things, I think Perl programmers have the ultimate "quick and dirty" mindset, but they're typically trying to solve different problems from a different perspective.
I also think a lot of the bitching about PHP is mostly because newer programmers are just repeating what they heard with the fervor of someone who doesn't work in PHP regularly.
Does it have problems? OH HELL YES. So does every language. Are the problems ever going to be fixed? OH HELL MAYBE. Is it the perfect hammer for every nail? OH HELL NO.
I work with what I know and I live with the problems because that's what I know. If I need new features, I'll work in another language, maybe.
No language is without issues. Except Python. Python is perfect.
Python is surely nice looking, but as it allows redefinition of everything at runtime, it is impossible to optimize at compile time. I think PHP, with the recent type strictness functionality, is better positioned for making way to new developments like meaningfull code analysis, (compile time) optimizations and performant JIT compilers. Python is too dynamic for that, unfortunately. The same holds for JavaScript.
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.
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.
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.