6 ms·

I don't think "PHP sucks!" - "no, it doesn't!" - "unless you can satisfy my 7 point list you are wrong and my biases are correct!" is a productive pattern of co

by Udo 11y ago

I don't think "PHP sucks!" - "no, it doesn't!" - "unless you can satisfy my 7 point list you are wrong and my biases are correct!" is a productive pattern of communication here, nor is chasing cheap applause lines by attacking a language every 'real hacker' is supposed to reflexively despise. If we're being honest every language has its weak points and things that are disliked even by its proponents. Efforts at improvement are more productively directed towards making things better on your own turf. Taking derivative and uninformed jabs at a language you already dislike and will never use is not a good way to spend your energy, nor is the energy of your opponents well spent in trying to overcome your biases.

nickpsecurity 11y ago
I mostly agree with you. Hence my list of key points that have been the reason for adoption of or migration from a language for production systems. Far from a jab, it's a start at objectively measuring PHP's value vs other languages. I actually have this data for a number of systems languages from studies done in 90's and early 2000's. Despite much talk, I've yet to see a PHP proponent post such objective information in a discussion. So I asked again as I know somebody has to have done an objective analysis or comparison. Yet again, all we hear is (a) critiques are BS, (b) many people use it, and (c) therefore PHP is a good choice. Sounds solid to me! ;)
- Udo 11y ago
  > the reason for adoption of or migration from a language for production systems People may think they choose languages and runtimes for objective reasons, but objectivity is only a part of it. There are other factors like ecosystem support, public image, fads, suitability for a specific purpose, aesthetic aspects, and how well a certain language resonates with someone personally. In this specific case, I believe there is zero value in convincing someone to use, say, PHP for something (in production or otherwise) if they already dislike the language for any reason. And it's not like you're missing out on anything either for not choosing PHP. There are plenty of options out there. > I've yet to see a PHP proponent post such objective information in a discussion. I'm probably not the best person to do this. While I use PHP and believe in certain contexts it's a good choice for me, I'm less sure about the benefits of evangelizing this in a greater context. There are lots of things in PHP that I actively dislike, as there are in any language I am proficient with. > (a) critiques are BS, (b) many people use it, and (c) therefore PHP is a good choice I think for several reasons PHP's advantages are minimized or even badly understood even by people who write big software packages in it. That's just my opinion, though. If you still want my atypical response to your points anyway, I'll give it.
  - nickpsecurity 11y ago
    "People may think they choose languages and runtimes for objective reasons, but objectivity is only a part of it." Oh I agree. It's why I don't knock them for whatever they use for personal projects. Serious stuff I recommend we throw the objectively best we have at. Not PHP or many others for that matter. "I think for several reasons PHP's advantages are minimized or even badly understood even by people who write big software packages in it. That's just my opinion, though. If you still want my atypical response to your points anyway, I'll give it." The one advantage I see is a ton of existing code and programmers to draw on. One of same advantages for C. Also, a great pre-processor for HTML crowd stepping into programming. Original selling point unless I'm mistaken with ColdFusion doing same thing in business for data-driven apps. Those are only two I know vs languages in same space. Certainly add anything that you think are advantages. I try to give everything a fair shake. ;)
    - 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.

by Udo 11y ago

nickpsecurity 11y ago

I mostly agree with you. Hence my list of key points that have been the reason for adoption of or migration from a language for production systems. Far from a jab, it's a start at objectively measuring PHP's value vs other languages. I actually have this data for a number of systems languages from studies done in 90's and early 2000's. Despite much talk, I've yet to see a PHP proponent post such objective information in a discussion. So I asked again as I know somebody has to have done an objective analysis or comparison. Yet again, all we hear is (a) critiques are BS, (b) many people use it, and (c) therefore PHP is a good choice. Sounds solid to me! ;)

Udo 11y ago
> the reason for adoption of or migration from a language for production systems People may think they choose languages and runtimes for objective reasons, but objectivity is only a part of it. There are other factors like ecosystem support, public image, fads, suitability for a specific purpose, aesthetic aspects, and how well a certain language resonates with someone personally. In this specific case, I believe there is zero value in convincing someone to use, say, PHP for something (in production or otherwise) if they already dislike the language for any reason. And it's not like you're missing out on anything either for not choosing PHP. There are plenty of options out there. > I've yet to see a PHP proponent post such objective information in a discussion. I'm probably not the best person to do this. While I use PHP and believe in certain contexts it's a good choice for me, I'm less sure about the benefits of evangelizing this in a greater context. There are lots of things in PHP that I actively dislike, as there are in any language I am proficient with. > (a) critiques are BS, (b) many people use it, and (c) therefore PHP is a good choice I think for several reasons PHP's advantages are minimized or even badly understood even by people who write big software packages in it. That's just my opinion, though. If you still want my atypical response to your points anyway, I'll give it.
- nickpsecurity 11y ago
  "People may think they choose languages and runtimes for objective reasons, but objectivity is only a part of it." Oh I agree. It's why I don't knock them for whatever they use for personal projects. Serious stuff I recommend we throw the objectively best we have at. Not PHP or many others for that matter. "I think for several reasons PHP's advantages are minimized or even badly understood even by people who write big software packages in it. That's just my opinion, though. If you still want my atypical response to your points anyway, I'll give it." The one advantage I see is a ton of existing code and programmers to draw on. One of same advantages for C. Also, a great pre-processor for HTML crowd stepping into programming. Original selling point unless I'm mistaken with ColdFusion doing same thing in business for data-driven apps. Those are only two I know vs languages in same space. Certainly add anything that you think are advantages. I try to give everything a fair shake. ;)
  - 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.