4 ms·

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 ho

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.

CharlesW 6y ago
> 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.)
- giantrobot 6y ago
  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.
  - Aeolun 6y ago
    > 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.
  - CharlesW 6y ago
    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/ https://slack.engineering/taking-php-seriously/
  - gremlinsinc 6y ago
    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.
- sergeykish 6y ago
  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.
Aeolun 6y ago
Maybe it was the default option on shared hosting because it was the only thing that could sort of reasonably work on shared hosting?
- giantrobot 6y ago
  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.

CharlesW 6y ago

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

giantrobot 6y ago
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.
- Aeolun 6y ago
  > 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.
- CharlesW 6y ago
  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/ https://slack.engineering/taking-php-seriously/
- gremlinsinc 6y ago
  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.
sergeykish 6y ago
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.

Aeolun 6y ago

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

giantrobot 6y ago
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.