Live data from Hacker News

Taking PHP Seriously

slack.engineering

361–370 of 673 posts

Re: Taking PHP Seriously

#361
post #359
post #353

Earlier quoted context omitted.

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.

The scalability of PHP is great, because each request is fully independent. This is like the Amazon lambda model. You /have/ to put your state in some storage back end, network attached RAM or such. This is a scalability best practice!

Yeah, but you also have to fork a whole process per request to do it.

Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request.

I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.

Re: Taking PHP Seriously

#362
post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

I'll offer an alternate hypothesis. Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to cherry-pick the winners and miss all of the t…

Brian, do you have any examples of companies that failed using PHP that you think would have succeeded with another interpreted language, and what problems did they run into that gave you this judgment?

Asking as I've developed in a slew of languages and never found the PHP-bashing credible. Most of the complaints seem to come from Rails people, but there are no shortage of MVC frameworks in PHP, including at least one that is a direct clone of Rails.

Re: Taking PHP Seriously

#363

Earlier quoted context omitted.

I'll offer an alternate hypothesis. Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to cherry-pick the winners and miss all of the t…

Brian, do you have any examples of companies that failed using PHP that you think would have succeeded with another interpreted language, and what problems did they run into that gave you this judgment? Asking as I've developed in a slew of languages and never found the PHP-bashing credible. Most of the complaints seem to come from Rails people, but there are no shortage of MVC frameworks in PHP, including at least o…

I've seen plenty of companies fail (or at least stall) because of technical debt. PHP certainly isn't to blame for that but it doesn't exactly lead by example either.

Re: Taking PHP Seriously

#364
Write an API for my client app which returns user's data as JSON (or render HTML page for profile);

You:

{

mysql_connect("host", "pass"); mysql_select_db("users");

$uid = $_GET[ "uid" ];

$res = mysql_query( "select * from users where uid = $uid" );

$ar = mysql_fetch_assoc( $res );

echo "name: " . $ar["name"] . ","; echo "location: " . $ar["location"];

?>

}

Just call it http://domain.com/api.php?uid=USER_ID

( Yeah I know you want to scream and say all the things about this code, but this is kind of code you would encounter with PHP, most of the time it's more horrifying than this one. )

People use it PHP for this reason, If you want to make same functionality in another language you need to setup an app and all the necessary things that protect you from garbage, some obvious security issues and bugs, not a single file like this. It's so easy and so wrong, it should be illegal to do this. Create a file and put it into directory and call it from your browser. You don't have to know anything about web or web servers and stuff. You just make shit by copying and pasting from internet, that's why Facebook made by PHP and now there are whole teams who are trying to protect company from PHP horrors. (They made a PHP VM, bunch of software to analyze PHP and optimize it etc. )

Just don't try to justify PHP, do not defend it. It's shit and you know it, accept it and move on.

(Note: do you remember Facebook's profile.php pages, they are still exists you can call it just like old times profile.php?id=YOUR_ID, yeah it's a shit once you get infected you're not gonna get out of it completely. Even if you can, it leaves traces on you just like profile.php URL's

Re: Taking PHP Seriously

#365
I find it odd that nobody sees the elephant in the room: productivity is determined by the "fit" between a developer's or team's mindset and the language!

None of them matter in isolation. If you have a team of people who likes to think dynamic, functionally and meta-linguistically, just pick the best Lisp-family language for your needs. For another team who prefers to think dynamic, functionally, with actors and pattern-matching, pick Erlang or Elixir. Someone who likes to think pragmatically, likes obviousness and simple static typing should probably pick Go if he's also "minimalistic" or Java otherwise. For a "move fast and break things + fuck this functional programming bullshit" thinking team, pick the best version of PHP (Hack & HHVM) etc. Want "move fast and break things + ok with event-driven + some sprinkle of functional programming goodness", then use Nodejs.

For example, for "move fast and break shit" prototype development I pick Nodejs over PHP because my mind "works functionally" and every attempt at writing functional code in PHP is pure pain.

There is a reason why there are so many languages: people think very very very differently from one another, but at the same time they think similarly enough that they can gather in "tribes" around certain technologies and idea!

Re: Taking PHP Seriously

#366
post #361
post #359

Earlier quoted context omitted.

The scalability of PHP is great, because each request is fully independent. This is like the Amazon lambda model. You /have/ to put your state in some storage back end, network attached RAM or such. This is a scalability best practice!

Yeah, but you also have to fork a whole process per request to do it. Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request. I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.

It is easy if you are just willing to spend more money on servers. Often it's worth it.

Re: Taking PHP Seriously

#367
post #350
post #45

Love the memes: "PHP is garbage language!", "PHP is a shitty language!" That is the antiquated view of course. The old days. Now with Laravel and PHP7 it is a pleasure to use. I'd go further. Working in Laravel is BETTER than ROR IMHO.

Have you used Rails in production? Just curious.

I've used both Rails and Laravel in production, and while I equally love both, the amount of hassles you face with rails in prod is an order of magnitude more.

rails + unicorn/passenger v/s apache + mod_php.

Re: Taking PHP Seriously

#369
post #361

Earlier quoted context omitted.

Yeah, but you also have to fork a whole process per request to do it. Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request. I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.

It is easy if you are just willing to spend more money on servers. Often it's worth it.

Only if you extract a ton of value per user or can serve a huge number of users per machine. Otherwise, upping the number of servers by an order of magnitude will start requiring an operations team to maintain.

That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.

Re: Taking PHP Seriously

#370
post #347

Earlier quoted context omitted.

Ooh. Mind, I agree with you, but given the Holy Documents Handed Down By Our Lord and Savior, Paul Graham, HN... might not be the safest place to say it. Edit: so, I'm clearly getting a lot of downs on this... maybe sarcasm in reference to PG was going a bit too far. Oh well. I'm not deleting or editing any of it, because that's sort of dishonest.

Sarcasm in general pisses people off, doubt it's anything Paul graham specific

Sarcasm pisses people off, or delights them. Or both.
Post reply on HN