3 ms·

> The one advantage I see is a ton of existing code and programmers to draw on I would not consider this an advantage per se, because exactly like C, it's diff

by Udo 11y ago

> The one advantage I see is a ton of existing code and programmers to draw on I would not consider this an advantage per se, because exactly like C, it's difficult to find a certain type of programmer who cares about things like performance or has a real understanding of what is happening when their code executes. I see the same thing happening in the Node.js community. (PHP, C/C++, and Node are my primary languages right now, I'm certain the same thing happens everywhere else, too) > Certainly add anything that you think are advantages. I try to give everything a fair shake. ;) How gracious of you :P As I said, I feel I'm not really representing the PHP community or the direction it's heading right now, but here's my view: As far as your points 1, 4, 6, and 7 are concerned - it's pretty much on par with other dynamic languages such as Lua or Ruby. My knowledge of PHP VM internals is limited, but as far as I saw last time, it's not fundamentally different from Lua's. There are some big WTFs in the syntax area, which I think is one of PHP's weakest points to begin with, but as far as expressivity and concision is concerned it's relatively powerful. Rubyists tend to talk about how speed is not important, which I disagree with, and PHP has never let me down in this regard. As for 2 and 3, well it's a dynamic language with an optional class system. As such it has the same weaknesses and strong points as other languages with those characteristics. Personally, I think PHP is strongest in fact without using the class system religiously, and instead making major use of its array/list type and functional code patterns. Which brings us to 5 and 6. PHP's unique strength and primary reason for me using it is its execution model in a web server environment. Every other language and web framework has gone the way of the application server, but PHP is using a per-request execution model which is incredibly powerful if used right. Per-request execution sounds like a high-overhead situation, and in the past it was, but while there is undoubtedly some cost associated with it, the FPM engine is really quite efficient with it. In exchange for this you get to benefit from a stateless app. If your code, the interpreter, or a library screws up, you're not taking down the server with it, you just disrupt the requests that actually hit the bug. You can tailor your app's code paths with this execution model in mind, loading and initializing only what you need. Since the environment is torn down after a request finishes, there are no leaks or complex GC gotchas. Scaling up becomes easy, because state is not stored in your code. You can spin up as many servers as you like, distribute requests among them, and they don't have to be aware of each other. Retracing what happens per request becomes very easy, which is great for optimizations and debugging. And you get live code reloading for free. I love this, it's so simple and elegant. Of course, there are lots of things this is unsuitable for, especially when you really do need a persistent app server. But even in these cases, it can be advantageous to write a small broker-style server in C or Node (or Go, or Erlang, whatever you want), and put the intelligence part in a PHP backend API. I use this setup in some projects where Websockets or other persistent protocols need to run: the broker needs to be updated very infrequently, so it can have a gigantic uptime, and the backend PHP API gets updated all the time transparently with a git pull - nothing needs to be restarted, everything just works.

jkarneges 11y ago
> the broker needs to be updated very infrequently, so it can have a gigantic uptime, and the backend PHP API gets updated all the time transparently with a git pull I strongly advocate this architectural style. Even for developers well-versed in Node, Go, etc, it's good defensive programming to split the application into two processes (broker and backend). You might find the Pushpin project interesting. It's an attempt at generalizing the broker part, and it works great with a stateless PHP backend.
- Udo 11y ago
  It's great to see I'm not alone :) > You might find the Pushpin project interesting. That is interesting, I didn't know such a project existed (kinda surprised actually). However, that's not a pain point for me at the moment. I maintain my own reusable broker module for Node/Websocket things, plug it into the NginX config and I'm ready to go. Plus it's not too hard to cook up one of these things if the need arises.
nickpsecurity 11y ago
"I would not consider this an advantage per se, because exactly like C, it's difficult to find a certain type of programmer who cares about things like performance or has a real understanding of what is happening when their code executes." I agree. It's one of the few things about PHP that you see in both lists of advantages and drawbacks haha. "As far as your points 1, 4, 6, and 7 are concerned - it's pretty much on par with other dynamic languages such as Lua or Ruby." I believe it for 1, 4, and 7 but am skeptical on 6: internal quality and security. The few times I saw people dedicate time to PHP vulnerabilities were finding them 10+ at a time. Lua and Go should do better due to simplicity but I haven't verified that. Coverity reported Python having lowest defect rate of about anything at one point. Getting updates on scoring like that vs other dynamic and static languages might be a useful metric. Compared to most web stuff, I'll leave 6 at maybe. "Rubyists tend to talk about how speed is not important, which I disagree with, and PHP has never let me down in this regard." They're foolish if so. Definitely a speed advantage for PHP given work (esp Facebook's) put into that. "Personally, I think PHP is strongest in fact without using the class system religiously, and instead making major use of its array/list type and functional code patterns." I believe that. It was true for some other languages before. So, that solves 2 but 3 is still on table. Languages supporting strong static analysis, design-by-contract, advanced typing, and so on can do better than a PHP-like language. This includes dynamic ones extended with that stuff. So, 3 is a maybe leaning towards no if against application rather than scripting languages. " PHP's unique strength and primary reason for me using it is its execution model in a web server environment. Every other language and web framework has gone the way of the application server, but PHP is using a per-request execution model which is incredibly powerful if used right." "In exchange for this you get to benefit from a stateless app. If your code, the interpreter, or a library screws up, you're not taking down the server with it, you just disrupt the requests that actually hit the bug." Definitely makes things easier to understand and reduces issues. Certainly an advantage against anything not supporting such a model where it's needed. Adds support on 5 given stateless reliability is easier to boost. " there are lots of things this is unsuitable for, especially when you really do need a persistent app server. " That's a lot of modern web apps, though, right? I can't guess at the percentage but "LAMP stack" implies databases and persistence are the norm. " it can be advantageous to write a small broker-style server in C or Node (or Go, or Erlang, whatever you want), and put the intelligence part in a PHP backend API." Smart idea. I can see the potential gains. There's parallels in highly assured systems where we kernelize critical functionality, implement it robustly, and untrusted stuff just calls it often with interface checks. It's a proven method with lots of application. Do you have any resources on doing this right in web applications out of curiosity? Just in case I have to get back into that. Conclusion We started with 7 metrics. Your case showed it's roughly comparable to competition in 4/7, probably better on 1/7, a maybe on 1/7, and a stronger maybe (stateless) on 1/7. Rather than horrible, with these metrics it comes out as OK in most ways with advantages in some and potential disadvantages in just a few. So, baring new data or metrics, it's objectively Ok at this point compared to others with possible advantages in speed or error minimization at component level. I say possible because I've seen competitors do similar things. I'd do case by case comparisons there but PHP is overall OK based on your data.

by Udo 11y ago

jkarneges 11y ago

> the broker needs to be updated very infrequently, so it can have a gigantic uptime, and the backend PHP API gets updated all the time transparently with a git pull I strongly advocate this architectural style. Even for developers well-versed in Node, Go, etc, it's good defensive programming to split the application into two processes (broker and backend). You might find the Pushpin project interesting. It's an attempt at generalizing the broker part, and it works great with a stateless PHP backend.

Udo 11y ago
It's great to see I'm not alone :) > You might find the Pushpin project interesting. That is interesting, I didn't know such a project existed (kinda surprised actually). However, that's not a pain point for me at the moment. I maintain my own reusable broker module for Node/Websocket things, plug it into the NginX config and I'm ready to go. Plus it's not too hard to cook up one of these things if the need arises.

nickpsecurity 11y ago

"I would not consider this an advantage per se, because exactly like C, it's difficult to find a certain type of programmer who cares about things like performance or has a real understanding of what is happening when their code executes." I agree. It's one of the few things about PHP that you see in both lists of advantages and drawbacks haha. "As far as your points 1, 4, 6, and 7 are concerned - it's pretty much on par with other dynamic languages such as Lua or Ruby." I believe it for 1, 4, and 7 but am skeptical on 6: internal quality and security. The few times I saw people dedicate time to PHP vulnerabilities were finding them 10+ at a time. Lua and Go should do better due to simplicity but I haven't verified that. Coverity reported Python having lowest defect rate of about anything at one point. Getting updates on scoring like that vs other dynamic and static languages might be a useful metric. Compared to most web stuff, I'll leave 6 at maybe. "Rubyists tend to talk about how speed is not important, which I disagree with, and PHP has never let me down in this regard." They're foolish if so. Definitely a speed advantage for PHP given work (esp Facebook's) put into that. "Personally, I think PHP is strongest in fact without using the class system religiously, and instead making major use of its array/list type and functional code patterns." I believe that. It was true for some other languages before. So, that solves 2 but 3 is still on table. Languages supporting strong static analysis, design-by-contract, advanced typing, and so on can do better than a PHP-like language. This includes dynamic ones extended with that stuff. So, 3 is a maybe leaning towards no if against application rather than scripting languages. " PHP's unique strength and primary reason for me using it is its execution model in a web server environment. Every other language and web framework has gone the way of the application server, but PHP is using a per-request execution model which is incredibly powerful if used right." "In exchange for this you get to benefit from a stateless app. If your code, the interpreter, or a library screws up, you're not taking down the server with it, you just disrupt the requests that actually hit the bug." Definitely makes things easier to understand and reduces issues. Certainly an advantage against anything not supporting such a model where it's needed. Adds support on 5 given stateless reliability is easier to boost. " there are lots of things this is unsuitable for, especially when you really do need a persistent app server. " That's a lot of modern web apps, though, right? I can't guess at the percentage but "LAMP stack" implies databases and persistence are the norm. " it can be advantageous to write a small broker-style server in C or Node (or Go, or Erlang, whatever you want), and put the intelligence part in a PHP backend API." Smart idea. I can see the potential gains. There's parallels in highly assured systems where we kernelize critical functionality, implement it robustly, and untrusted stuff just calls it often with interface checks. It's a proven method with lots of application. Do you have any resources on doing this right in web applications out of curiosity? Just in case I have to get back into that. Conclusion We started with 7 metrics. Your case showed it's roughly comparable to competition in 4/7, probably better on 1/7, a maybe on 1/7, and a stronger maybe (stateless) on 1/7. Rather than horrible, with these metrics it comes out as OK in most ways with advantages in some and potential disadvantages in just a few. So, baring new data or metrics, it's objectively Ok at this point compared to others with possible advantages in speed or error minimization at component level. I say possible because I've seen competitors do similar things. I'd do case by case comparisons there but PHP is overall OK based on your data.