Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
1. Way to easy to create security holes due to the nature of the language (such as functions exposing the whole env) and the ecosystem around it (apache gladly serving everything there is by default)
2. Awful bloated syntax
3. Scope? Pfffft nah let's make everything global. But not that. And not this.
4. Created as a personal tool but went global and wasn't handled properly from the beginning -
Me neither, it pays my mortgage and gives me holidays and booze and has done for the past 22 years. Never had any issues or security breaches. But I only produce SME web stuff with CMS. Nothing overly complex. Don’t do Turdpress though.
-
A lot of the hate for php comes from the language it was 20 years ago, and the *terrible* products that were created with it that *were* full of security holes, even if the language itself wasn't.
That being said, while it's better now, it's still not one I'd particularly choose to use. -
After decades of slow but steady improvements, it is a bearable language now.
But the standard library still is an inconsistent mess of different naming conventions, argument orders and some still return unexpected magic values like -1 or false for edge cases. The standard library is basically full of noob traps and i still use wrappers around it all.
And as literally every weakly and dynamically typed language, it has its fair share of quirks (no, you can't have a string key looking like an int in your arrays - array keys are always of a string|int union type) that make it harder to go all-in type safety with tools like PHPStan.
If you do something new, use a strongly and statically typed language from the start. Weak typing is for prototyping only and prototypes almost always end up becoming procuction code in practice. The concept of prototyping languages has failed. Go for the final language from the start. -
The origin of PHP I read bout is this. This guy was trying to show people how to do web stuff with C/C++. They kept saying it was "too complicated". So he wrapped the stuff he was doing in PHP. From what I gather he didn't know much about creating languages. People started using it. It just kept going. So it was supposedly a way to reduce complexity for the masses.
-
php has traditionally often caused security holes. many php-sites over the years have leaked secrets due to stuff being public by default, and many popular php products were said to be poor. For example many bots today still look for WordPress sites with open user endpoints. I also hear debugging and error handling used to be poor, and some standard libs would throw errors in unexpected ways.
PS: this is mainly what I hear -
One minor thing php used to get dissed for over a decade ago (but not as much anymore) was that many beginner php projects ended up being a single file. "mixing logic and presentation is bad" was a mantra. Basically having html and logic in the same file (beyond what was than necessary to render the Html) was seen as bum code. This was perhaps during the MVC heyday when separation of concern into layers was seen as the default sane way. But a common joke since the rise of frameworks like React is that "this is not that far from php"
-
As someone that has: used it pre version 5 (yes, I strted on the 4 days) has dealt with "A Fractal of Bad Design" issues and a lot of different shitty codebases: I get it, but still PHP is fucking awesome.
I get it because it really gives a lot of power to developers when building websites. It is the "shoot yourself in the foot" of web languages, but honestly, a lot of those issues are prevented by understanding the web and by extension understanding the language.
PHP forever man. Got an entire life because of it. -
IMHO @Oktokolo @AleCx04 described it best.
https://php.net/manual/en/...
For the history.
There is one aspect though that rubs me the wrong way.
The security part.
It would take a rant the size of a book to elaborate on that in a good manner, so here is the short version:
1) CGI / Webserver security
2) PHP security
3) Code security
4) Common sense security
These 4 usually get mixed into one "PHP is insecure" type of bag.
Though it has nothing to do with language at all.
1) is a general problem of anything running a webserver or CGI process. Webserver running under root is my favorite example, as then - of course - PHP runs via CGI under root and security is moot. Yeah ... That was common for a long time cause of the "permissions are hard" mentality. Could mention more like allowing symlinks, the ht file abusage, and so many other things.
2)
https://cvedetails.com/cvss-score-c...
NodeJS
https://cvedetails.com/cvss-score-c...
PHP
Tip the Group By Year checkbox, rerun it. Node is just the Node runtime, thus the CVEs for all the packages that add in e.g. JSON / file parsing / ... would need to be added.
Not saying PHP is a saint, just that other languages don't look way better - if one accounts that PHPs stdlib includes file -/ io operations and other things.
3) Code security. Oh girls and boys, I could tell you stories of crap code that burned my eyes like ammonium... But yeah. Many projects lacked QA, good coders and a security first perspective. Goes for any language. To stay with NodeJS: Look at the messy packets. :)
4) Common sense
E.g. passing a file as a path to a backend. This works in any language. Now common sense would be to make sure that the file is an actual file and is in the project directory... Yet this is one of the most common security holes. -
So. PHP security = bad, but compared to others - accounting for stdlib - not really that bad.
-
I had a lot of fun with it but would never switch back to it from python. PHP vars are just not object so you get many functions like array_merge, array_sort etc like it's C.
Edit: define vars with dollar sign is not a bad idea. No keyword conflict. With python you add a _ after a var name if you conflict with keyword. That's 'pythonic' -
@WillemD good article. It has a link to: https://blog.codinghorror.com/php-s... listing all keywords beginning with an a. Imagine that python only has 35 keywords in total
I've honestly never understood the reason behind the hate PHP gets.
Almost everyone says they hate it, but I am yet to see a proper explanation for it.
rant