Live data from Hacker News

Taking PHP Seriously

slack.engineering

31–40 of 673 posts

Re: Taking PHP Seriously

#31

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT.

You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.

Re: Taking PHP Seriously

#32
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've been in the game long enough to realize how true this is. Good point. It will certainly make people here defend their sacred choices.

Re: Taking PHP Seriously

#33

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

> "reasoning about" (boy do I hate that phrase...)

A bit tangential, but I find myself disliking it too, for no good reason that I can think of.

Perhaps it's something of a crutch in that it's really "I like it more, but 'reason' sounds better" ? Not sure that's quite it, either, as in the above case with a "new everything per request", it's certainly true that it's easier to think about what's happening.

Re: Taking PHP Seriously

#34
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…

Love this comment. I'm a PHP dev.

I do care about my code though. I think you can write niceish code, even with a shitty language.

Re: Taking PHP Seriously

#35
post #21

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

>>Why are there no other "competitors" in this space? There are. Any language that supports either fastcgi, or runs as an apache plugin (or similar) functions in the "each request starts new" space. There's certainly others, but Python and Perl are both good examples. Starting new with each request does, of course, mean lots of re-work that shouldn't have to be done with each request. It does initially keep complexit…

I mean more of languages that actually "target" this kind of setup.

I know it can result in a lot of "extra work", but I really feel like most of the pain of that could be abstracted away by the runtime.

Nginx/apache setup a PHP process before the request comes in, so why couldn't you expose that point to your language and let the programming language do work before that point, even "snapshot"ing it to avoid re-doing that work for each request?

It just seems like there are better ways of solving this problem, because an event loop is such a "hammer" solution to the problem.

Re: Taking PHP Seriously

#36
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…

Or because it had first mover advantage in its cohort.

Re: Taking PHP Seriously

#37
post #10

For greenfield project main question would be why? It's not horrible but what do you exactly gain? With so many options around it's actually hard to make a case for PHP (and I have being using it since 2000).

It's extremely mature, stable, reliable, and easy to reason about.

Personally I wouldn't choose it but, for a larger company, if you already have engineers that know it - and trust me many will - it's not a bad choice.

This is especially true if you are just serving a simple website for a product or service, even basic e-commerce. 90% of websites out there don't need Rails, or Python, or Go, or Node.

Re: Taking PHP Seriously

#38
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…

But what about all of the successful Haskell startups? /s

Re: Taking PHP Seriously

#39
post #30

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

Exactly. The "shared nothing lifecycle" really lets the programmer (knowingly or unknowingly) embrace RESTful design. Too bad the language doesn't have strict typing like Java. Otherwise it'd be even more convenient and safer in my eyes.

PHP 7 actually has strict typing like java, but no generics.

It’s really interesting, last time I worked with PHP was a few years ago, then recently I wrote something in PHP 7, and it is a lot safer.

(But still no compile time type checking because there is no compile time).

Re: Taking PHP Seriously

#40
post #29

Earlier quoted context omitted.

I'm currently hesitating between PHP and Node.js for a new side project and I'm leaning towards PHP simple because I could do it 50% faster due to my experience with it.

Node is actually one case where depending on the project it could be very easy to make a case for PHP :) if you need a simple API backend you can use PHP and not deal with whole async thing.

Actually for that project Node would have an advantage over PHP with job handling and realtime functionality.

But currently I only care about a fast MVP.

Post reply on HN