The bad rep is totally deserved. PHP, for most of its existence, has been a profoundly bad language per se. That doesn't mean nobody's ever built anything valuable on top of it, and I fully understand that (much like also-justifiably-maligned JavaScript) it's evolved quite a bit. But the points made in this mid-2012 article are absolutely spot-on in describing precisely why PHP absolutely earned its reputation: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
This back and forth appears in every single thread about PHP on HN:
- PHP doesn't deserve its bad reputation!
- Well, it used to be pretty terrible...
- Ok, so first let's talk about the relativity about the definition of "terrible". The Oxford English dictionary defines [...]
And from there it goes nowhere.
It is true that PHP improved drastically over the past decade or so, it is also true that it used to be a garbage fire of a programing language and ecosystem.
For the PHP proponents in the comments: I think you'd save you a lot of trouble if you didn't try to dismiss the history of PHP and pretend that it was just unfair criticism from haters. It was warranted. You can't win this one.
But who cares? If PHP really is good now you're way better off arguing about that, because while you'll never manage to convince me that it was a good language in 2005, you might end up convincing me (and others) to give it a try in 2020.
I don't know how it looked like in the US, but in several European countries the web was basically built in PHP. In 2005 the entire web market in my country was PHP with a few uncool Java enterprisey jobs here and there.
Being able to mix PHP and HTML code was brilliant and setting up PHP on a server was child's play compared to Java. Because state was stored in the DB and individual pages were ephemeral, we didn't have any issues with e.g. memory usage or performance.
At that time I was already familiar with C, C++ and C# and I didn't find it worse to use PHP. It was a good match for the job.
In 2020 the number one OWASP security risk is injection and I don't think anyone's arguing that the current crop of languages are all crap.
Evaluating a language without judging what kind of projects it enables is nonsensical and leads to pointless language ivory tower discussions. I'm sure that also back then there were all sorts of awesome programming languages that nobody was using, but checked all the boxes that would make the average HN language enthusiast happy.
As a counterpoint, the number one cause of death in America in 1950 was heart disease. It’s also the number one cause of death today. We’ve still made a lot of progress in treating heart disease in the last 70 years
What kind of progress have we made since 2005 in preventing (not treating) SQL injection? I remember reading a book about PHP security that year where escaping strings and bound parameters were mentioned.
Just don't construct SQL queries by directly concatenating user input. It's easy to mess up or use the wrong escape function, so always use prepared statements anywhere you want to pass user defined data.
You can usually grep or even use static code analysis to help find where your existing code is using "tainted" data to construct a query.
Also, if you use an ORM, you'll generally be working at a high enough level where SQL injection is impossible (unless there's a bug or design flaw in the ORM); since you won't be directly dealing with text queries.
2005 means PHP 5/5.1. It may suck in retrospect, but it was fine at the time, and there were a lot fewer choices. There are excellent reasons why it powered (and continues to) large swaths of the web.
I think a lot of the misunderstanding around PHP's past stems from its accessibility. But real software developers had no problems creating real software with it even then, and since then the ecosystem has become startlingly better.
> …you might end up convincing me (and others) to give it a try in 2020.
It's been in the TIBOE top 10 since it's debut in 2001. If you haven't tried it by now, it seems unlikely you ever will (and that's absolutely fine).
PHP 5 wasn't fine at the time which is what the GP was saying. It was inconsistent and stupid and only carried on because it was the default option on shared hosting so everyone could easily throw up their b2^H^H Wordpress blog.
PHP would have been abandoned years ago if not for Wordpress' worse is better success story.
> PHP 5 wasn't fine at the time which is what the GP was saying.
"Fine" (as in "adequate") is not a high bar, and so is easily defensible. I get that it's fun to say that PHP was "stupid", but history shows that PHP's historic imperfections didn't prevent developers from building everything from web-scale apps (Facebook, Wikipedia, Flickr, Tumbler, etc.) to, yes, millions of blogs.
(Don't get me wrong, your favorite language seems nice too.)
History shows successful projects built no matter what. It does not mean they would be successful if started with same technology today.
Unfortunately programmers rarely decide language of the project. Usually it is a sales team. Projects impossible to migrate and we stuck. If language does not match either rewrite, split service/extension or use polyglot like GraalVM.
Big websites used PHP in the distant past and have a handful of lines running today. PHP is eating the world!
Come on man, you're well aware none of those "web scale" companies are running major portions of their sites on PHP anymore. Well, you should be aware of that.
You can keep fighting for PHP if you want. Don't pretend that it's worse is better nature fifteen years ago somehow made it a good language or that it didn't have major failings.
I wrote a ton of PHP 3 through 5. It was easier to deploy on $10 shared hosting than Perl/CGI and more capable than SSI. That was about it in terms of its advantages at the time. It wasn't easier to write than Perl and in fact had more and less obvious footguns. It's database access was shaky at best and downright dangerous at worst.
The question today is why bother with PHP for greenfield development? It doesn't really offer anything unique or special. You can't really leverage your PHP skills anywhere but web development and really only a subset of that field. So good luck with that.
What I actually said was PHP 5 was "fine". To that I'll add the wildly controversial assertions that PHP 7 is "pretty good" and PHP 8 "looks nice".
I know that I'm supposed to have internalized that PHP Is Bad, but occasionally I have to do maintenance on a PHP project and I just can't find it within me to hate it.
> It was easier to deploy on $10 shared hosting than Perl/CGI and more capable than SSI.
Exactly. And for other folks who (unlike us) didn't use PHP at the time, the "Virtues of PHP" section of this Slack post that lists other notable reasons why people chose (and still might?) PHP: https://slack.engineering/taking-php-seriously/
is there any cli for scaffolding a site that includes auth, caching, sessions, queues, teams, profile, 2-factor, rbac (via policies), migrations, asset management via webpack with low-to-no config... (sure this is just for laravel, but that's a huge subset of users, just as django/rails are for python/ruby)
Even rails doesn't have auth baked in. For launching something fast, nothing beats prototyping in laravel. For more heavy work-loads you can offload services to go or rust for data intensive things, and still keep the majority of the code/api.
For new devs especially, community matters more than just about anything. While, wordpress is a clusterfuck of security issues, vulnerabilities, and bad practices the laravel community and (symfony which is more for enterprise apps) are generally top notch.
Show me how you can bootstrap a full SaaS app w/ all the same features as:
laravel new myapp --jet --teams
In ANY language without using some sort of cookiecutter template, or something that is custom-brewed.
Most shared hosts also supported CGI with scripts/binaries in a set cgi-bin directory. A lot of them (that I ever saw) even had some preinstalled CGI scripts linked into the user account's cgi-bin.
What a lot of shared hosts did not support were things like mod_cgi or mod_rewrite that might let you make cleaner looking URLs. With PHP you just enable mod_php and add index.php to the DirectoryIndex directive and call it a day. Many hosts didn't allow overrides so you couldn't add a CGI handler to your DirectoryIndex unless you knew the server admins.
So like I said, PHP was the easiest to get running. It wasn't the only thing that worked or was supported but it made it simple to have URLs that looked "professional" with no access to a server's configuration and no ability to override defaults. So it worked well for cheap shared hosting.
I'm still annoyed I know this stuff almost twenty years after having to deal with it. People really wanted their brand new .com address to serve up their "dynamic" homepage with nothing hanging off the path. PHP was the worst is better way to make that happen.
Case in point, after coming to the conclusion that XML + XSLT wouldn't last for my web site, I went to search for something else, and wasn't that happy with my ISP alternatives (PHP + CGI/Perl).
However, after a couple of trials with other stacks, I ended up going with PHP, it does the job, was already on the ISP without me having the hassle of being a special snowflake, I was anyway the only one coding it and now get to enjoy a JIT compiler that Python and Ruby communities are still not fully embracing on their reference implementations.
And although I do mostly Java/.NET Web related projects, I do occasional PHP projects, because after I am done, I am sure that the customer is going to have an easy time finding someone else to take care of their issues, as I don't want to make a living out of it.
When PHP was first released it was dramatically better than the alternatives for it's intended purpose.
There were plenty of things to complain about, but none of them stopped you from doing useful things with it. It was never slow or inefficient compared to other scripting languages, it didn't lack functionality.
Over the decades the most popular complaints have been addressed as the language has matured.
That it's remained in active development for 25 years with no signs of that changing in the future is one of it's biggest selling points.
I don't blame people for having issues with aspects of PHP based on their personal preferences and experiences, I get that, but that doesn't make it a 'bad' language.
There's nothing wrong with purist perspectives on what programming languages should be and how they should work. That contributes to better design.
But in the real world the questions are simpler: can this tool be used to develop applications quickly? Is it reasonably efficient at runtime (in this case in the context of scripting)? Can we easily find affordable developers in the future? Is there community support?
PHP checks the boxes that people building things want checked as well as any language and better than many. Unless I'm missing something, 'bad' here is more of a philosophical stance.
I mean there are some quite uncontroversial languages. For instance Python. What surprises me the most, C is segfaulter #1 but literally nobody complains about that because it works good enough and the code is elegant. I think it still holds the position of most beloved systems programming language
Plenty of people complain about Python - about the language itself (significant whitespace, dynamic typing and excessive complexity), about the implementation (slow and limited by the GIL) and about the ecosystem (e.g. https://xkcd.com/1987/).
A self argument is on methods because then, from the inside, methods are identical to functions, rather than functions with additional implicit magic.
Also because it's a function member of the class with exactly that argument pattern; calling instance.method(...) is just syntax sugar for ClassOfInstance.method(instance, ...).
This also makes Python handling of unbound methods a lot cleaner than, say, Ruby.
Segfalter is a feature which prevents release of weak code by weak people. Granted such approach isn't suitable in enterprise where Java rules because any kitchen sink of staff thrown together in
Java still runs somehow, yet in systems you must meet orders of magnitude higher threshold.
Bad type coercion you can’t turn off with weird semantics. Powerful but confusing arrays/dictionaries. Inconsistently named stdlib functions with inconsistent parameters. Little to no support for threading or concurrency models outside of making event loops or running multiple processes. Memory management that allowed for leaky memory all the time. Lack of proper support for stand-alone daemon processes (you could make it work but it was clearly not the main way PHP was meant to be run). Lack of namespaces or modules with all variables being global.
This was PHP 5 and it sent me running for the hills (Python, ES6). I am sure PHP 8 is an improvement and I’ve worked with PHP versions past 5.3 but it left such a bad taste in my mouth that yes I will avoid it if I can. Fixing what shouldn’t have been broken may make this language almost as good as something like Python but why would I reach for PHP when better things exist unless that decision is not made by me?
> Little to no support for threading or concurrency models outside of making event loops or running multiple processes.
Having just started with programming, this is more feature than bug. It’s super easy to reason about PHP applications because the whole flow is linear from top to bottom.
Not sure what you mean about global variables. PHP 5 had the same scoping rules like it has now. You couldn't access global variables directly from anywhere but the toplevel execution context.
That’s a problem. Same with every function and class name. Oh and requiring/including a file is not idempotent because it’s just string concatenation because they are not modules. None of that should be a part of a modern language. If they haven’t fixed that in PHP 8, then it’s still broken.
There is an argument for judging programming languages based on the worst code possible within the language, due to the fact that with a wide enough ecosystem, you will regularly encounter lots of stuff in the median between that and your “just don’t do that” standard.
This is one of the reasons I love Go: the worst code possible in it is still pretty readable.
The worst code possible in PHP is scattered across thousands of files corresponding to individual routes, and isn’t indented at all.
But PHP makes it way too easy and provides few ways to guard against it. Well technically now it does with namespaces but that’s still less than ideal. And my point is that they are just now starting to catch up to more sane languages.
That’s a hack, not a solution. You still can’t import just class A out of A, B, and C that are all defined in the same file. And even if you require_once file x.php, you don’t have any guarantees that that file won’t require/include file y.php that you also intend to include. PHP files are treated as files, not modules and that’s fundamentally broken.
I guess you like modules. Someone else may like string inclusion, because it allows for some other forms of splitting the code that modules would not allow and fulfills the primary purpose of a PHP script, which is templating. Neither is fundamentally broken. You're just focusing on one aspect (organizing code), while ignoring the other.
Ah and there it is. PHP is fundamentally a templating system with a programming language built-in. Imagine using Handlebars.js to write your business logic.
I do think code organization is one of the primary jobs of a programming language/ecosystem. I want my tools to help me be better about that, not worse. Oh and given that most projects use a bunch of library code, I would very much prefer a system that has a consistent code organization pattern so I don’t have to guess how it all works. Take a look at the source code for something like WordPress or WooCommerce. These are mature projects. And yet it’s hard to shake the feeling that it’s all spaghetti inclusions.
> I do think code organization is one of the primary jobs of a programming language/ecosystem. I want my tools to help me be better about that, not worse.
Isn’t splitting up all your classes into separate files considered to be a good thing?
Considering how huge we can make files in JS I’m sort of inclined to consider that a problem instead of a feature.
I think any project that started around PHP 4/5 will look like Wordpress. Looking at more recent projects (after PSR’s became a thing) would be more representative.
It is but when you use third party code, what guarantees do you have that it didn’t do something stupid like declare a variable like $TIMEOUT? Whether on purpose or by accident. And of course any class or function become global even if you run include/require inside the body of a function or a method.
Include inside the body of an anonymous function if you care about toplevel $TIMEOUT=123 overriding some global variable.
Anyway you don't have any guarantees in JS either, for example. Imported module can just redefine Date object prototype or any global via globalThis. If you don't trust the libraries to not make a mess, don't use them is the only real solution. And it will be completely silent as opposed to PHP failing loudly when you try to redefine constant or class or function.
> When PHP was first released it was dramatically better than the alternatives for it's intended purpose.
I think that's going to depend to some degree on how you define that purpose. If it centers around having a low barrier to entry, then that's partly true, but some of the ways it achieved that involved making code written in it vulnerable to variable poisoning and SQL injection by default.
CGI didn't have register_globals, so yes on that count. I'm sure the quality of database access libraries varied, which is still a better situation than having a broken escape function built in to the language.
Well register_globals was a kind of uniquely php thing, but that's been gone for ages at this point. I generally agree though that lots of the hate for php is a bit over the top.
It is not possible to use language without documentation, should name include underscore? Where to put string? I've switched to ruby, it is predictable.
Mixed baggage of C, Perl, Java influences, no design. PHP 4 had design, PHP 5 made it total mess.
Borne shell good in gluing UNIX tools, AWK good in simple columnar data, PHP good in one page scripts.
Yes, but 2012 is 8 years in the past. Do you know what else is 8 years in the past? Well, not Reacts first release because that happened only in 2013. That's how long 8 years are in web terms.
At some point — and boy, are we long past that point — it feels old when gramps goes off about the woes of PHP4 because, oh, it feels like it's just been yesterday.
This is why PHP deserves it's reputation. The state of the language is one thing, the state of the ecosystem surrounding the language is another.
Anecdotally speaking, the vast majority of PHP projects I've been exposed to have been horrific precisely because there's a laissez-faire or "get the job done at any cost" attitude to software development that's uniquely prevelant in these communities (this exists in all languages, but in my experience it's way worse and way more normalized within the PHP silo). The language improving will only be positive for new projects that are started today, or that have been maintained by dilligent and empathetic engineers. Often teams are not as united on this front as they should be.
I think using almost any other comparable language in 2020 (Python 3, Go, Typescript) is a better solution than starting a new project in PHP these days. I suspect the real reason many still reach for PHP first is because it is "easy" and PHP developers are ostensibly cheap and easy to replace. It's a false economy.
And next you‘re telling how terrible COBOL is? Seems like most/many banks are still running on cobol today...
I think just because something was bad before yesterday does not mean it cannot be used in good ways today or tomorrow. And I think everybody talking bad about PHP should not even think about JavaScript.
Todays PHP gets its job done in a really good way. It has very good frameworks, is amazingly fast and is easy to start with and quite easy to deploy. And it‘s absolutely not comparable to something that was many years ago. And I think too, PHP before something after PHP 5.5 was not „that good“ compared to C# or Java.
>The bad rep is totally deserved. PHP, for most of its existence, has been a profoundly bad language per se.
Javascript too, so what? In the end it's another tool with specific pros and benefits, and it got many things right (ease of deployment, no shared state, batteries included, etc).
JavaScript was a bad language though, if not just from it’s messy origins. There’s been a ton of work put into the language and lots of thought put into the ’good parts’ to use and expand upon.
I’d be interested in learning more about php’s evolution, and possibly even a follow-up to that article.
I have written both PHP and JS for a living since about 2005 (for my sins) and I can tell you PHP has gone through at least as much of an evolution as JS. Neither one feels anything like its 2005 ancestor.
I started programming with PHP back in 2001, I think. I moved to C# when dotnet was released shortly after, but still have a personal website that's built with PHP, and a couple of years back I updated it (from something like PHP 4/5, I forget) to the latest version PHP. I was pleasantly surprised - it wouldn't be my first choice by a long shot, but I can see why others would choose it today. And there's always been a good community around it too.
I also started with JavaScript a long time back, maybe something like 1998-1999. I've always found it a most loathsome language, and the anaemic standard library a huge barrier. It's not entirely the language's fault, of course - being the language of the web was always going to mean glacial progress. Recently I worked on a vanilla ES6 project (since browser support is finally there), and at long last I wouldn't quite describe it as "loathsome" anymore! Still, it's a far cry from the nicities of Typescript, and the tiny standard library remains an issue.
Having seen both PHP and JavaScript evolve over around 2 decades, I'd probably argue that PHP has evolved more as a language than JavaScript has.
JavaScript even in 1996 was much saner language than PHP. Surely there were bad parts, but in JS you could just ignore them. In PHP on the other hand one had to build on top of bad parts since there was no good alternatives.
In JavaScript you still have to deal with all the bad parts. That’s why we pretty much require monstrosities like babel, webpack and whatever other build tools you can imagine.
If you want PHP, you install php, and you’re done.
Someone posted an article above [1], but citing from it, there is a function called mysql_real_escape_string. Although early JS also has quite odd language choices, it follows a consistent philosophy. To me it boils down to LISP in C syntax with weak typing. Past PHP feels more like a collection of stuff. But I assume modern PHP can be a viable choice if used with a modern framework, linter etc.
PHP follows a consistent philosophy as well. The PHP functions are usually named after the C functions they wrap. And in fact: The MySQL C client library contains a function called mysql_real_escape_string.
can someone explain to me why it should print out 'horse'? (what the article above says)
on edit: oh I get it, the false of the ternary statement here is on the left so when $arg == 'T' the true does ( $arg == 'H' ) which is false, hence printing out horse.
Well there's no reason true has to come first, but it is a c-flavored language so sort of weird it doesn't.
I haven't used PHP is a professional project for probably 10 years, aside from needing to poke around in Wordpress occasionally. When I see modern PHP, I barely recognize it.
So what operating system do you use? Unix is 50. Windows is 35. Linux (even if it is Unix) is 30. I can't think of any commercially viable operating system that has been released in the past 20 years.
Most is 51%. If PHP was bad from 1994 to 2002, when "A Fractal of Bad Design" was written (18 years), and is OK now (assuming it got good immediately after that post was written 8 years ago), it has been bad for most of its existence by simple arithmetic.
The FA itself points readers to Python (with Flask, Pyramids, or Django), and also gives an offhand mention of Ruby + Rails and Perl + Catalyst. Java had also become a pretty reasonable language & environment by this time, and off-beat "let's build a better language on top of an existing runtime/ecosystem" languages like Clojure and F# were in full swing.
PHP was already very successful before Django or Rails even had their first release.
I remember trying to set up a Python Django web site for the first time around 2010 because Python seems like the better language and it was such a PITA compared to PHP's it-just-works nature.
PHP isn’t exactly an elegant language, and I would argue that you need to be an pretty good developer to write safe PHP code. Still PHP is easy to get startet with, well documented, productive and impressively fast for a “bad” language.
If you know what you’re doing I don’t see any reason to not pick PHP.
This sentence really got me thinking. "Deserved" is some sort of moralistic word, I'm not sure how it applies to a tool, unless it means to apply to the makers and/or users of the tool.
And I guess it makes some sense. A bad reputation is a sort of social communication utilizing shame and stigma. Maybe it causes people not to use PHP without having to pay the cost of really understanding why, which is likely only accessible with lots of experience and/or study.
This is basically by definition an inaccurate bias, of lacking nuance, but perhaps a net good. If PHP was such a poor tool for productivity and security then it was probably good if shame and stigma were helping people to use better tools without paying the cost themselves first.
But it's always very frustrating if you actually know what's bad and what's good about a thing, or even just know that it has both bad and good parts (even if you don't know precisely which is which), and you see a memetic belief held up as truth rather than acknowledged as a useful heuristic.
And while it feels dirty, maybe this shame and stigma also serves to influence the creators of the language and its ecosystem to make it better. I don't know. I hope there are better ways than shame and stigma but I'm just a d00d writing a post on a web forum.
What does seem clear to me, though, is if is a good tool NOW, as a result of years of work by the people who kept at it, then a bad reputation is no good anymore; no longer a positive force but a negative one.
Is C undefined behavior and use after free "shame" or "stigma"?
JavaScript has bad parts and design (and big community that claims it is fine language), Perl has great design and small community (and everyone can bash it), PHP has horrible design flows and a big community that does not address issues from "Fractal of bad design" but claims language is fixed.
As experienced developer I know what good design is. This article saved a lot of novices from trapping into badly designed language as a first one.
At least some PHP proponents makes fools of themselves:
> This of course is coming, like usual, from someone who spent a significant portion of their life in academia and then moved to R&D and still has yet to make a dent in the world, or likely their student loans [1].
Words of true believer. PHP can't transition to not bad language because of such believers. Those who can see faults left. And what's left is echo chamber. There would be no break of backward compatibility. I've checked, from design perspective nothing changed.
All I see is community discarding critique without addressing it or even understanding it.
I think in this case "deserved" was used in the same sense as "warranted," although I realize this doesn't change the main point you're making.
What you're getting at is that people can be influenced by factors other than objective truths. I admit that I am someone who tries to avoid making decisions based on word-of-mouth or "reputation," but you can't deny that only considering objective truths takes a lot of work.
Sometimes I just want to buy a keyboard, not read and apply "The 50 Tenets of Keyboard Comparison" to find the objectively best (for me) keyboard.
It makes sense how this attitude can bleed into decision-making as a whole, even for higher-impact decisions like programming language choice. So I wouldn't discredit (or lower the reputation of ;) ) too much the folks who don't always go by objective truth.
> PHP, for most of its existence, has been a profoundly bad language per se
I mean, people often say the same thing about C, C++ and Java. But these are also massively popular languages, so obviously they're doing _something_ right and the people complaining must be looking at the wrong metrics.
"PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening."
