The Only Argument You Will Ever Need Against PHP
Your article vents about the frustration of working on someone else&#x27;s code, when you have the advantage of hindsight and something that works at least somewhat. That has nothing to do with PHP. I think you should examine your assumptions.<p>&gt; ...in 20 years, I&#x27;ve never encountered a situation in which I needed something PHP does that something else didn&#x27;t.<p>Fine, but just a few paragraphs later you actually describe what PHP does that other things don&#x27;t: allows less experienced&#x2F;skilled programmers to get something to work quickly and deploy it easily. That actually has tremendous value to a lot of businesses.<p>&gt; ...mopping up some hacked or otherwise messed up doo-dad or other, because the person who put it there couldn&#x27;t.<p>Maybe the person who put it there just ranks way below you in terms of skill. Or maybe they had budget and time constraints and an anxious customer in a hurry to get something working on a $10&#x2F;month shared hosting setup.<p>&gt; I feel injured by this. I feel robbed.<p>With all respect, grow up. If you take code this personally -- especially someone else&#x27;s code -- you show an immature and elitist attitude toward your profession.<p>&gt; This kind of expertise arbitrage, where the skill level you need to set something up initially is nowhere near the skill level you need to fix it when it breaks, is pervasive in the software industry...<p>Yes, the entire profession of programming rests on what you call expertise arbitrage. It may derive from the difference between my expertise and my client&#x27;s, or my expertise and the previous developer. We make money from the arbitrage. If you don&#x27;t like that kind of work don&#x27;t take on those jobs.<p>&gt; If an attacker can smuggle a PHP file onto your document root, then they can execute it. If they can do that, then they own you. This attack vector cannot be eliminated. If you use PHP, you will always be fighting it. Forever.<p>If someone can smuggle a file into your document root or anywhere else on your server, you have a problem no matter what language. You can mitigate this risk easily with well-understood practices for PHP and server configuration. I have worked mostly with PHP for almost 20 years and have actually never seen this happen, though I have found sites that could allow it (and I fixed the problem easily). No one is constantly fighting this problem forever.<p>&gt; Once again, this situation is not unique to PHP, it&#x27;s just that PHP is where you&#x27;re most likely to see it. This issue also isn&#x27;t strictly about document roots, but more about the level of control over what code gets executed. It&#x27;s the difference between a default-deny policy and default-allow.<p>People who work with web apps see more problems with PHP because PHP dominates the web application space by a very wide margin. The last time I saw a web app with huge security holes (200 failures in an automated security audit) it was Ruby&#x2F;Rails, not PHP.<p>&gt; PHP web apps can be made to run out­side the doc­u­ment root just like any­thing else, and in­deed this is how mod­ern MVC frame­works op­er­ate. Sure they can, but then you ob­vi­ate the point of using it. If you aren&#x27;t going to be plunk­ing files into your doc­u­ment root for im­me­di­ate ex­e­cu­tion, you may as well use some other stack.<p>Sure. You miss an even more important reason for choosing PHP: the relatively mature library&#x2F;frameworks available, and the huge number of PHP programmers relative to other web-ready languages. If I sell my client on a Haskell or Smalltalk solution because I hate PHP, I may have done my client a serious disservice because they will have a harder time finding someone capable of working on that. Or maybe you mean Java or Node.js or .Net, all of which have their own security and deployment issues.<p>&gt; What kind of jobs though? Mopping-up jobs, of course. Moreover, on the other side of that job is an employer, who is more than happy to take advantage of all this competition. If you aren&#x27;t working at Facebook, the Wikimedia Foundation, Automattic or Acquia, it&#x27;s probably worth asking yourself, dear PHP developer, if you are being played.<p>Nope. First, 90% of programming amounts to what you call &quot;mopping up&quot; and what the rest of us call maintenance and enhancement. Limiting yourself to green-fields projects in your preferred language won&#x27;t lead to employment for most programmers. And you misunderstand how competition for jobs works -- PHP developers can and do make just as much as people working with other stacks.<p>&gt; Expertise arbitrage, though, irrespective of its substrate, is very real and very much a liability. This to me makes one&#x27;s choice of stack more than just a matter of taste: it&#x27;s an object of organizational design.<p>What does that even mean?<p>&gt; And if that isn&#x27;t good enough, I can tell you from experience that banning PHP will eliminate aeons of monotonous tweezing out of Russian dick-pill spam.<p>No, it won&#x27;t. Banning open email relays would help with that particular problem, but that has nothing to do with PHP. Programmers will always vary greatly in skill level and we will always have a lot of low-quality software running in production. Get over yourself.