Hacker News Reader

Comment by simias | Hacker News Reader

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.

View on HN

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.

But the web was also made of SQLi and reverse shells in 2005 as well.

Nobody should argue the utility of using php in 2005; just as nobody should argue that it wasn't also a superfund site of a language in 2005 as well.

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.

I don't disagree that the web was basically built on PHP in 2005, but in 2020 that isn't really the case anymore.

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.)

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.

> It's database access was shaky at best and downright dangerous at worst.

Lol. It literally offers you ‘one’ function to access the database. Any insecurity is your own fault.

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.

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.

Maybe it was the default option on shared hosting because it was the only thing that could sort of reasonably work on shared hosting?

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.

Reply on news.ycombinator.com