Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

211–220 of 673 posts

Re: Taking PHP Seriously

#211

Post by Jach »

bpicolo wrote: post #182
greenhatman wrote: post #34

Earlier quoted context omitted.

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.

PHP always reminds me of the Dijkstra quote: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

Me too. My first language was PHP, I wonder what that's done to me. :) I still appreciate it, and kind of wish other languages had a "from webdevstuff import *" feature that would just bring everything I might need for the purpose of web dev into the namespace, rather than many lines of imports from sometimes obscure paths. I can't get on the hate wagon with the rest of the community. I'll avoid using it to start anything new, of course, but I'd take it over any other mainstream option. Give me Clojure or Lisp and I'll be happiest though.

Re: Taking PHP Seriously

#212

Post by leeoniya »

bpicolo wrote: post #187
leeoniya wrote: post #179

Earlier quoted context omitted.

I can't tell you how much more "runtime state" exists in PHP than in say Java. In both cases you need to initialize some sort of security-aware context. Once you've eliminated parsing, disk i/o and compilation phases. You should be on pretty even ground of bytecode vs bytecode. Java has a Hotspot JIT, so it will probably win there. I think a JIT is coming to PHP as well since the architectural rework that went into P…

There's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens. In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality

if you need to persist some data/state between requests, php has a mature memcached extension. it's a fast memory store, but i'm not certain of the security implications since i dont think it has any kind of built-in isolation.

Re: Taking PHP Seriously

#213

Post by [deleted] »

bkanber wrote: post #198
tonyarkles wrote: post #106

I've been doing consulting for several years now, as well as a MSc thesis that involved me looking at a number of open source codebases. I am generally in the "PHP is garbage" camp, but I keep hearing people say that nice codebases in PHP are possible. I've never seen one, but I am perpetually open to the idea that they exist. Does anyone have a good example of an open-source PHP project that will enlighten me?

Symfony, Aura, Laravel, Guzzle, Composer, Zend Framework, Lithium, SwiftMailer

[deleted]

Re: Taking PHP Seriously

#214

Post by tonyarkles »

bkanber wrote: post #198
tonyarkles wrote: post #106

I've been doing consulting for several years now, as well as a MSc thesis that involved me looking at a number of open source codebases. I am generally in the "PHP is garbage" camp, but I keep hearing people say that nice codebases in PHP are possible. I've never seen one, but I am perpetually open to the idea that they exist. Does anyone have a good example of an open-source PHP project that will enlighten me?

Symfony, Aura, Laravel, Guzzle, Composer, Zend Framework, Lithium, SwiftMailer

Those are all frameworks and libraries, aren't they?

Re: Taking PHP Seriously

#215

Post by bkanber »

mikey_p wrote: post #72
Klathmon wrote: post #11

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…

The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialize…

> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request.

So? If it takes We serve most of our requests in < 10ms, and we're not even on PHP7 yet.

Re: Taking PHP Seriously

#216

Post by icedchai »

I do Java and python for my day job, but do quite a bit of PHP on the side (small consulting projects, etc.)

The main advantages of PHP are ease of deployment (no build required, just upload your files and go, use a shared web hosting or a cheap VPS) and a fast dev cycle (edit/refresh the page.) It's also simple to work with for web designers who don't have a lot of back-end knowledge. They can edit your templates and see results instantly.

For anything with complex business logic, background processing, etc. it's absolutely the wrong choice. However, for basic web apps, when combined with a good framework (such as Laravel), it is fast and productive.

Re: Taking PHP Seriously

#217

Post by weberc2 »

tyingq wrote: post #193
weberc2 wrote: post #145

Earlier quoted context omitted.

The real question is why does PHP depend on globals or thread locals for request state at all? PHP's "new process per request" is a solution to a problem that PHP created for itself. In other languages, the request handler receives the request state as an argument, so when the request completes there is no state to reset. > It seems like it would be easier for everyone involved. You wouldn't need much of a GC when th…

>>PHP's "new process per request" is a solution to a problem that PHP created for itself True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Combined with the now bundled opcache, the re-work per request is limited to the developer's own…

> True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out.

The OP's question wasn't scoped to the mid-90s.

> PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process.

Like I said, the same holds true even for an OS thread. Anyway, if it's not a new OS process, then some sort of GC is needed, contrary to the OP's statement.

> Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.

Again, these are all solutions to problems PHP invented for itself. Other languages don't require special caching mechanisms; they get by on normal scoping rules and shared memory.

Re: Taking PHP Seriously

#219

Post by bpicolo »

leeoniya wrote: post #212
bpicolo wrote: post #187

Earlier quoted context omitted.

There's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens. In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality

if you need to persist some data/state between requests, php has a mature memcached extension. it's a fast memory store, but i'm not certain of the security implications since i dont think it has any kind of built-in isolation.

Sure, but that means I have to either run a memcached instance on every server (which I've actually had to do before just for the sake of PHP) or I have to make network calls for something I shouldn't have to, and then also do serialization/deserialization. That's fine for plenty of things, but certainly isn't optimal for all sorts of stuff.

Not to mention, all the other languages out there memcached just as well.

Re: Taking PHP Seriously

#220

Post by bkanber »

bpicolo wrote: post #187
leeoniya wrote: post #179

Earlier quoted context omitted.

I can't tell you how much more "runtime state" exists in PHP than in say Java. In both cases you need to initialize some sort of security-aware context. Once you've eliminated parsing, disk i/o and compilation phases. You should be on pretty even ground of bytecode vs bytecode. Java has a Hotspot JIT, so it will probably win there. I think a JIT is coming to PHP as well since the architectural rework that went into P…

There's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens. In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality

Session cookies were basically invented for transient statefulness over HTTP.
Post reply on HN