6 ms·

C or C++ aren't competing with PHP. You'd have to look at Python or Ruby in this case. While it's definitely possible to write shitty code in those languages it

C or C++ aren't competing with PHP. You'd have to look at Python or Ruby in this case. While it's definitely possible to write shitty code in those languages it doesn't provide nearly as many ways to screw up. Besides the lack of language features like @ (error silencing), you won't find nearly as many terrible tutorials out there created by some guy who's been learning for a few weeks and decided to write a blog post. Given a poorly engineered PHP or Python project, I will always pick the latter. However, if I were to start a project on my own I'm confident enough in my PHP that the language choice is harder to make.

vectorpush 14y ago
C or C++ aren't competing with PHP. That's true, but my point is that there isn't such a visceral hatred for C and C++ even though they are widespread and notorious for memory leaks, vulnerabilities, indecipherable corporate quagmires (perhaps due to an over-engineered OO architecture or 700 line functions or opaque symbol names or dependency hell, etc). Besides the lack of language features like @ (error silencing) Red-flag bad practices exist on all platforms. The horror story of a PHP project littered with error suppression is like opening up a C project and discovering that the control flow is guided by a 200 label GOTO architecture. It's not PHP's fault that the programmer abuses the language, it's the employer's fault for hiring a highschool student at $15/hr.
- 10098 14y ago
  > indecipherable corporate quagmires (perhaps due to an over-engineered OO architecture ...) Sounds like Java to me :-)
- nupark2 14y ago
  > That's true, but my point is that there isn't such a visceral hatred for C and C++ even though they are widespread and notorious for memory leaks, vulnerabilities, indecipherable corporate quagmires (perhaps due to an over-engineered OO architecture or 700 line functions or opaque symbol names or dependency hell, etc). C is enormously more consistent, better defined and specified, and well-documented than PHP. It's a solid enough language with a very specific use case, and not even remotely competing with PHP. PHP is a terribly inconsistent, poorly defined, poorly documented, poorly implemented, poorly designed language that can't do anything better than any of the other languages it is competing with. The one thing PHP has going for it is inertia. That's it.
  - vectorpush 14y ago
    C is enormously more consistent, better defined and specified, and well-documented than PHP. Yes, this is a trite and negligible truth of PHP. A developer suffering any significant loss of productivity due to problems like mismatched needle/haystack parameters just isn't very competent. It's a non-issue if the developer is being paid a real salary. I'm not saying these issues aren't important enough to warrant attention, but the debate between maintaining backwards compatibility and squashing bad practices certainly isn't exclusive to PHP. and not even remotely competing with PHP. I already addressed this in my previous post. I'm not suggesting that PHP is in competition with C, that should be pretty obvious. I'm asserting that C, like PHP, is ridden with dangerous pitfalls for developers who don't know what they're doing. PHP is just easier to work with for a novice programmer. The one thing PHP has going for it is inertia And did that inertia spontaneously emerge from a vacuum? In the spirit of PHP's namesake you've devised a recursive argument to explain the only conceivable upside to using PHP.
    - nupark2 14y ago
      > Yes, this is a trite and negligible truth of PHP. A developer suffering any significant loss of productivity due to problems like mismatched needle/haystack parameters just isn't very competent. It's a non-issue if the developer is being paid a real salary. I'm not saying these issues aren't important enough to warrant attention, but the debate between maintaining backwards compatibility and squashing bad practices certainly isn't exclusive to PHP. You're just hand-waving away the issue. "Yes, you have to keep far more in your head at once to make sure you don't step on a PHP landmine, but that's why we're paid the big bucks!" I'm sorry, but this is a false dichotomy and an inaccurate parallel with C. C's landmines are well-defined, understood, and derive from the target purpose (portable assembly). PHP's landmines are ambiguous, ill-defined, and just plain stupid, often caused by what amounts to a truly brain-dead lack of cognitive effort on behalf of the language authors. The language is poorly specified such that even if a developer should wish to invest sufficient effort, it's impossible to know where they all are. Moreover, there are such ugly corner cases built into the language and common libraries that some landmines are entirely unavoidable. Whose brilliant plan was it to make fopen() accept URL parameters instead of defining a common stream API that arbitrary stream types could support? Let's say I want to treat a byte array as a stream -- this is a pretty common thing to do in most languages: fopen('data:text/plain;base64,'.base64_encode($data), 'rb'); Are you bloody kidding me? That's just the smallest, tiniest tip of the PHP iceberg of stupid-in-action. > And did that inertia spontaneously emerge from a vacuum? In the spirit of PHP's namesake you've devised a recursive argument to explain the only conceivable upside to using PHP. PHP's inertia emerged out of ill-qualified individuals adopting the language as the most visible available option during a time when there was largely a dearth of options and limited understanding of the web as a platform and "what comes next" from CGI. People -- collectively, as a group -- adopt poor solutions to their problems, simply as a matter of compounding gravitation and a lack of understanding of the long-term implications. It's simple group decision making, and it's not reasoned, nor is it necessarily likely to produce the best possible answer, or even a good one -- especially when the group in question is ill-equipped to understand the problem space they're working in.

vectorpush 14y ago

C or C++ aren't competing with PHP. That's true, but my point is that there isn't such a visceral hatred for C and C++ even though they are widespread and notorious for memory leaks, vulnerabilities, indecipherable corporate quagmires (perhaps due to an over-engineered OO architecture or 700 line functions or opaque symbol names or dependency hell, etc). Besides the lack of language features like @ (error silencing) Red-flag bad practices exist on all platforms. The horror story of a PHP project littered with error suppression is like opening up a C project and discovering that the control flow is guided by a 200 label GOTO architecture. It's not PHP's fault that the programmer abuses the language, it's the employer's fault for hiring a highschool student at $15/hr.

10098 14y ago
> indecipherable corporate quagmires (perhaps due to an over-engineered OO architecture ...) Sounds like Java to me :-)
nupark2 14y ago
> That's true, but my point is that there isn't such a visceral hatred for C and C++ even though they are widespread and notorious for memory leaks, vulnerabilities, indecipherable corporate quagmires (perhaps due to an over-engineered OO architecture or 700 line functions or opaque symbol names or dependency hell, etc). C is enormously more consistent, better defined and specified, and well-documented than PHP. It's a solid enough language with a very specific use case, and not even remotely competing with PHP. PHP is a terribly inconsistent, poorly defined, poorly documented, poorly implemented, poorly designed language that can't do anything better than any of the other languages it is competing with. The one thing PHP has going for it is inertia. That's it.
- vectorpush 14y ago
  C is enormously more consistent, better defined and specified, and well-documented than PHP. Yes, this is a trite and negligible truth of PHP. A developer suffering any significant loss of productivity due to problems like mismatched needle/haystack parameters just isn't very competent. It's a non-issue if the developer is being paid a real salary. I'm not saying these issues aren't important enough to warrant attention, but the debate between maintaining backwards compatibility and squashing bad practices certainly isn't exclusive to PHP. and not even remotely competing with PHP. I already addressed this in my previous post. I'm not suggesting that PHP is in competition with C, that should be pretty obvious. I'm asserting that C, like PHP, is ridden with dangerous pitfalls for developers who don't know what they're doing. PHP is just easier to work with for a novice programmer. The one thing PHP has going for it is inertia And did that inertia spontaneously emerge from a vacuum? In the spirit of PHP's namesake you've devised a recursive argument to explain the only conceivable upside to using PHP.
  - nupark2 14y ago
    > Yes, this is a trite and negligible truth of PHP. A developer suffering any significant loss of productivity due to problems like mismatched needle/haystack parameters just isn't very competent. It's a non-issue if the developer is being paid a real salary. I'm not saying these issues aren't important enough to warrant attention, but the debate between maintaining backwards compatibility and squashing bad practices certainly isn't exclusive to PHP. You're just hand-waving away the issue. "Yes, you have to keep far more in your head at once to make sure you don't step on a PHP landmine, but that's why we're paid the big bucks!" I'm sorry, but this is a false dichotomy and an inaccurate parallel with C. C's landmines are well-defined, understood, and derive from the target purpose (portable assembly). PHP's landmines are ambiguous, ill-defined, and just plain stupid, often caused by what amounts to a truly brain-dead lack of cognitive effort on behalf of the language authors. The language is poorly specified such that even if a developer should wish to invest sufficient effort, it's impossible to know where they all are. Moreover, there are such ugly corner cases built into the language and common libraries that some landmines are entirely unavoidable. Whose brilliant plan was it to make fopen() accept URL parameters instead of defining a common stream API that arbitrary stream types could support? Let's say I want to treat a byte array as a stream -- this is a pretty common thing to do in most languages: fopen('data:text/plain;base64,'.base64_encode($data), 'rb'); Are you bloody kidding me? That's just the smallest, tiniest tip of the PHP iceberg of stupid-in-action. > And did that inertia spontaneously emerge from a vacuum? In the spirit of PHP's namesake you've devised a recursive argument to explain the only conceivable upside to using PHP. PHP's inertia emerged out of ill-qualified individuals adopting the language as the most visible available option during a time when there was largely a dearth of options and limited understanding of the web as a platform and "what comes next" from CGI. People -- collectively, as a group -- adopt poor solutions to their problems, simply as a matter of compounding gravitation and a lack of understanding of the long-term implications. It's simple group decision making, and it's not reasoned, nor is it necessarily likely to produce the best possible answer, or even a good one -- especially when the group in question is ill-equipped to understand the problem space they're working in.