Thanks for the comment!

As a counterpoint, I used PHP5 when writing https://www.goldeneaglecoin.com/ and it was always < 50 ms on my endpoints, running on some crusty hosted celeron at the time. Adding caching and opcache doesn't invalidate the stateless approach.

Programming is about adding abstractions on top of underlying computational substrates. Ultimately our CPUs don't care if we run haskell or PHP, they just run machine instructions. I never found it too complicated to use useful abstractions in PHP.

I usually prefer inheriting a subperforming cache-free PHP site, because devising a consistent cache strategy is usually not too hard (cache static content + opcodes on deploy, determine which invalidation keys you need for the subset of dynamic content that does the bulk of the load / has latency requirement, don't cache the rest). If I have a big collection of lose php files, that's reasonably easy to do. If i have a tangled web of middlewares and ORM'd business logic, it's much harder, and I usually have to unfold it to "lose leaves".

Great comment! You clearly are well-versed in the ecosystem much more than when my PHP5 self gave up. If I needed a PHP dev for a project, I'd hire you.

> Adding caching and opcache doesn't invalidate the stateless approach.

> Programming is about adding abstractions on top of underlying computational substrates. Ultimately our CPUs don't care if we run haskell or PHP, they just run machine instructions. I never found it too complicated to use useful abstractions in PHP.

I'll push back a little on these. TL;DR: it's a trade-off.

My point with Haskell is that the entire language itself is stateless, so if per-request statelessness ("shared nothing") in PHP is a virtue, then certainly total statelessness ("purity") in Haskell is even more of a virtue. The problem is that, despite having similar performance to PHP, Haskell is hard to write.

This is illustrated with caches: if a PHP program had a line something like `if ($cache.retrieve('foo') != null) { echo "Success!<br />"; } else { echo "it's broken"; }`, then now global state matters again.

Haskell doesn't allow code of this form, but forces you to think harder about how to make it work using e.g. monads, and this can be frustrating. But if you can get Haskell to work, you can get caching nearly for free.

for sure. but it's not "hard" (of course abstraction is hard to learn and see, but not to implement, I hope you understand my meaning here. I apologize for the lack of clarity) to build something like (very rough sketch):

  function get_all_products() {
     return cached(function () { return Sql::Select(PRODUCT_TABLE); }, Cache::GetSessionCacheKey());
  }

  render_template(Page::GetTemplate(), 
     [ "products" => get_all_products(), 
       "user" => get_user_data()
     ]);

or as I did for https://goldeneaglecoin.com/ , I would internally route "HTTP" calls, so the javascript and PHP would look identical:

  /* 
   * @url: /products
   * @cache: session(1h)
   */
  function get_products() {
     return Sql::Select(PRODUCT_TABLE);
  } 

  render_template(HTTP::GET("/templates/products"), HTTP::GET("/products");

while the javascript looks like:

  GET("/products").then((products) => render_template("/templates/products", products))

The caching is declarative, and the code is "stateless." This is fast enough that caching the render is pretty much not necessary, despite running on a t2.medium, and easily sustains > 100 rps. In the happy path, it reads a single value in the object cache. Only an initial hit will cause a render (using a bytecode compiled optimized template), and only the first XHR will cause an actual lookup in the server side cache (if necessary) because the browser then does the rest.

I wrote this code 12 years ago, and porting to react doesn't require any change on the server side. We just put RTK-Query in front and let it do all the rest.

PHP5 to 8 is night and day in terms of performance just on its own, they're not really comparable.

> I can't speak about the latest stuff, but PHP5 in ~2014-15 was...

I don't understand the purpose of your post.

Do you judge all languages according to your experience from 8 years ago?

Do you go on python boards telling everyone how much you hate working with python 2.7?

Maybe spend your afternoon on rust threads to complain about it not being available to the public yet?

Do you need to like a language for 8 entire years before letting anyone know about it, or just some time within the past 8 years?

> I don't understand the purpose of your post.

GGP was wondering why there were downvotes rather than comments detailing disagreements.

I decided to write down the reasons why I personally would not touch PHP again rather than give a downvote.

Maybe PHP8 or PHP7 or whatever it is (I know they skipped 6?) is awesome, but I've moved on.

Also, FWIW, a few of my objections are certainly still relevant based on the claims in GGP's post and some cursory review of the documentation, particularly around caching & in particular op caching.

> Do you judge all languages according to your experience from 8 years ago?

No, only ones that left mental-emotional scar tissue.

> Do you go on python boards telling everyone how much you hate working with python 2.7?

Python 2.7 was highly pleasant. I wouldn't use it now, but it didn't abuse me. :)

> Maybe spend your afternoon on rust threads to complain about it not being available to the public yet?

GGP: <X> is awesome for these reasons!

GGP: HEY! Why are people downvoting rather than commenting?

GP (me): Here's why your reasons don't persuade me based on my admittedly outdated experience

P: Why are you so critical?

> Do you need to like a language for 8 entire years before letting anyone know about it, or just some time within the past 8 years?

Non sequitur. But the answer is no.

Perhaps it might be more productive if someone commented which of my claims are obsolete rather than ad hominem them. I know that those relating to compilation, deployment & statelessness are still valid, given GGP's comments and my cursory examination of the PHP docs, plus experience with other platforms.

Maybe modern PHP has truly excellent performance. Maybe using a breakpoint debugger has been solved now. Maybe design is better, e.g. the standard lib has functions that can work with arrays as lists and arrays as dicts without being surprising (e.g., `filter()` used to preserve all indexes, since it treated arrays as dicts from numbers to values; often, you needed to use fold/reduce or a loop to re-number after a filter).

> That is a ton of wasted work, and there are literally sections in the PHP docs about tools to circumvent this problem.[0]

Install opcache, done. No need for hyperbole.

Good to know it's that easy.

Do you ever run into race conditions? And how does it handle cache coherency?

Opcache is integrated into PHP since 5.5. It's been stable for around two decades.

https://www.npopov.com/2021/10/13/How-opcache-works.html