I saw such a post on X: "Why half the internet still runs PHP."
https://x.com/artillain/status/2113018532980211928
What do you guys think?
This guy seems to imply that C code tends to be longer than PHP code. But I don't think that point hits the nail on the head. If a C programmer feels the code is unnecessarily long, they can simply create functions with granularity similar to PHP's features.
I think PHP's value lies elsewhere.
If you "simply create functions with granularity similar to PHP's features" you're basically re-implementing PHP from first principles. The advantage of PHP over C is that you don't have to do that. A lot of PHP is just wrappers around C anyway.
And yes the fact that it's easy to serve a website from PHP is a big part of its value, all else aside.
Thank you for your opinion. I agree: "A lot of PHP is just wrappers around C." In fact, we can also find PHP functions with the same names as in C. We can also save effort by using these wrapper functions.
Therefore, I believe it is misguided to compare code volume to suggest that one language is superior or inferior to another. If the volume of code were the basis for such a judgment, then machine language would have to be considered the most inferior language of all.
PHP is basically the Ur-implementation of Server-Side rendering and processing. JSP's and a bunch of other technologies are basically "PHP, except in-house" relative to other programming languages. As one of the earliest impl's of that that I'm aware of, it's also got the beefiest stdlib, and most eyes-on time. It was basically the JS of it's era. The value-add was that you once you implement the templates & widget toolkits, your designer could mix and match those elements for an arbitrary set of UI impl's without having to worry about leaving the php ecosystem. (I.e. abstraction + 1), and you get that "dynamic web page" experience where pre-PHP, you didn't have it short of writing a task specific, full featured native client, which was a different impl for each OS, and often meant implementing Yet Another Bespoke RMI implementation to get to your data sources anyway. PHP allowed abandoning the windowing toolkits and finicky clients, and just using a web browser + http. The drawback being all the dynamicity was entirely dependent on the server-side, meaning scaling your user population required beefier and beefier servers since the server was doing all the work. Eventually, the blight of JS happened, and the architect's realized they could dump the rendering work on caller's machines. It's all about tradeoffs. In a world with clients which were much less powerful than server hardware, and sketchier network speeds, PHP made the most sense. With hardware capable of running at clock speeds on par with server hardware, and broadband speeds broadly available, there's a case to be made for making the caller's hardware do more of the work. Personally, I think the server pages ultimately kept the incentives aligned better, but no one really asked me, and apparently the bean counters like externalizing costs wherever they can.