Hacker News Reader

Comment by cwt137 | Hacker News Reader

I don't like how the author of the article said that PHP is an interpreted language and thus does not execute anything like Java is executed.

I'm not saying PHP executes just like Java, but PHP is more like Java than he realizes. PHP does not execute line by line like an interpreted language. But takes the source and compiles it down to an intermediate representation (IR), just like Java. Java calls it bytecode, PHP calls it OPCodes. Also like Java, PHP then takes that IR and executes it on a VM. Java's is stack based and PHP is register based, if I remember correctly. Many PHP accelerators / caching solutions save the IR and thus, the next time the code is needed, no compilation of source code is done.

View on HN

I can't count how many times I have seen someone effectively say "My thing is better than your/that thing" but they have not actually researched what the other thing is or how it works, they just simply like their own thing so much that they automatically assume it's better or this case different.

Often in corporate environments people are asked to justify a choice of technology, and an approach to a problem. It is quite natural for the people making the decision to choose technology they're most familiar and comfortable with, and positioning it in a favorable light. I imagine this is what happened here.

The actual merit of the competing technology is simply not part of the evaluation. This is at least a step up from government procurement processes where the procurement officer, who has zero technical knowledge, procures based on a checklist he or she is unable to correctly assess bidder responses to, and of course price.

Maybe the article means that PHP interprets the OPCodes as opposed to java that uses a JIT compiler that produces machine code for part of the bytecodes. Anyway JIT is coming with PHP8 :

https://stitcher.io/blog/new-in-php-8

The key difference between Java and PHP is the lack of a compilation step. I can change a line of code, press cmd+r and I see the change - whereas in Java more often than not I have to wholly restart the application container as hot-reloading is a complicated mess and tough to set up.

Also, in Java it is easy to end up with resource leaks whereas PHP always starts from a clean slate for each request. Way less headache for operations.

Right, but in a corporate production environment where everything is probably deployed compiled or compiled shortly after, does that matter? No one is altering prod code.

It certainly makes zero or almost no downtime deployments easier. Assume a Java application with a database that accesses said database during initialization - for a schema change you have to take great care in code that both the old and the new code can concurrently work on the same database to achieve low downtime.

With a PHP application, it's easier - spin up the new Docker container, disconnect the loadbalancer, do the schema change, and connect the loadbalancer to the new Docker container.

> Also, in Java it is easy to end up with resource leaks whereas PHP always starts from a clean slate for each request. Way less headache for operations.

That assumes you're running a new separate PHP processes for each request and an application built this way is unlikely to scale terribly well.

> That assumes you're running a new separate PHP processes for each request and an application built this way is unlikely to scale terribly well.

No. PHP always wipes the complete execution stack even in a long lived execution model like FPM or Apache mod_php.

Reply on news.ycombinator.com