I mean no disrespect to you, but this sort of thing is exactly the sort of mess I’ve come to expect in any randomly-selected bit of PHP code found in the wild.
It’s not that PHP somehow makes people write terrible code, I think it’s just the fact that it’s been out for so long and so many people have taken a crack at learning it. Plus, it seems that a lot of ingrained habits began back when PHP didn’t have many of its newer features and they just carried on, echoing through stack overflow posts forever.
The saving grace of JS is that the ecosystem had a reset when React came out; there's plenty of horrifying JQuery code littering the StackOverflow (and Experts Exchange!) landscape, but by the time React came around, Backbone and other projects had already started to shift the ecosystem away from "you're writing a script" to "you're writing an application," so someone searching "how do I do X react" was already a huge step up in best practices for new learners. I don't think PHP and its largest frameworks ever had a similar singular branding reset.
The other thing making JavaScript a little better in practice is that it very rarely was used on the back end until Node.js came along, and by then, we were fully in the AJAX world, where people were making AJAX requests using JavaScript in the browser to APIs on the back end. You were almost never directly querying a database with JavaScript, whereas SQL injection seems to be one of the most common issues with a lot of older PHP code written by inexperienced devs. Obviously SQL injection can and does happen in any language, but in WordPress-land, when your website designer who happens to be the owner's nephew writes garbage, they can cause a lot of damage. You probably would not give that person access to a Java back end.
I'd argue that PHP7 is the closest thing PHP has had to a quality revolution. It fixed a zillion things, got rid of some footguns like legacy mysql, and in general behaved a lot more rationally.
If you were doing things right, by that point you were already using Laravel or Symphony or something, so the change didn't seem as revolutionary as it was, but that was the moment a lot of dumb string concatenated query code (for example) no longer worked out of the box.
I've heard it said that one of the reasons Fortran has a reputation for bad code is this combination: lots of people who haven't had any education in best practices; and it's really easy in Fortran to write bad code.
Most horrific code I've ever seen was a VB6 project written by a mainframe programmer... I didn't even know VB6 could do some of the things he did... and wish I never did. Not to mention variables like a, b, c, d .. aa, ab...
Something like half of of reported JavaScript vulnerabilities are "prototype pollution" because It's very common practice to write to object keys blindly, using objects as a dictionary, without considering the implications.
Yeah, same with the use of "filter_input_array", "htmlspecialchars", or how you should use PDO and prepare your statements with parameterized queries to prevent SQL injection, etc.
On a new job I stuck my foot in it because I argued something like this with a PHP fan who was adamant I was wrong.
Mind you this was more than ten years ago when PHP was fixing exploits left and right.
This dust up resolved itself within 24 hours though, as I came in the next morning to find he was too busy to work on something else because he was having to patch the PHP forum software he administered because it had been hacked overnight.
I did not gloat but I had trouble keeping my face entirely neutral.
Now I can’t read PHP for shit but I tried to read the patch notes that closed the hole. As near as I could tell, the exact same anti pattern appeared in several other places in the code.
I can’t touch PHP. I never could before and that cemented it.
I mean, in this case the developer really went out of their way to write bad code. TBH it kind of looks like they wanted to introduce an RCE vulnerability, since variable variable assignment is well-known even to novice PHP developers (who would also be the only ones using that feature), and "eval is bad" is just as well known.
A developer who has the aptitude to write a whois client, but knows neither of those things? It just seems very unlikely.
Pretty sure C++ has 1/10 or fewer the all-time practitioners PHP has, so while I'm sure plenty of bad code is available out there, I still would not expect the situation to be as bad as PHP.
There is no PHP at Amazon (at least not 2009-2016). It was evaluated before my time there and Perl Mason was chosen instead to replace C++. A bunch if that’s still appears to exist (many paths that start with gp/) but a lot was being rebuilt in various internal Java frameworks. I know AWS had some rails apps that were being migrated to Java a decade ago, but I don’t think I ever encountered PHP (and I came in as a programmer primarily writing PHP).
I was probably one of the few who enjoyed Mason and still think the aggregator framework was great. We implemented a work-a-like in Java on Prime and it worked great there as well. It was effectively GraphQL before GraphQL, but local and remote, async, polymorphic, and extremely flexible. Not being in that world anymore I’m not sure if there is anything else quite like it, but there really should be.
To paraphrase: you can write PHP in any language. PHP is a negative bias for bigCo mostly because of the folkloric history of bad security practices by some PHP software developers.
You're saying all big companies ban whole language ecosystem because somebody on the internet used one function in that language in knowingly unsafe manner contrary to all established practices and warnings in the documentation? This is beyond laughable.
Does exactly what? Ban whole ecosystems because somebody on the internet used it wrong? Could you please provide any substantiation to this entirely unbelievable claim?
PHP provides a built in escaper for this purpose
But even then you don't need eval here! Is all you really needed... but really just use an array(map) if you want dynamic keys... don't use dynamically defined variables...