311–320 of 402 posts
Earlier quoted context omitted.
That's what makes the statement "no 'unknown unknowns'" a bit ridiculous though. How can you possibly assert that there are absolutely NO 'unknown unknowns'? You can never rule them out, and at best can only suspect there's a possibility either way, that they do or do not exist. You can never actually know with certainty.
Schrödinger’s Cat?
PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
I’ve always wondered why the more respectable dynamic languages, like Ruby and Python, don’t have a web framework with the PHP deployment model of “just upload this file to the server and refresh your browser to see changes.”
Earlier quoted context omitted.
I’ve been using PHP since 2003 and it’s my full time job and this doesn’t ring true. Very, very rarely is a gotcha not in the docs comment section.
That’s just it. I have to code with the PHP docs open like some kind of arcane recipe book.
(a) you're a true, deep expert who uses the language all day every day
(b) the docs are so poor it's not even worth having them open
Earlier quoted context omitted.
I’ve always wondered why the more respectable dynamic languages, like Ruby and Python, don’t have a web framework with the PHP deployment model of “just upload this file to the server and refresh your browser to see changes.”
They do. It's just that everyone seems to have collectively decided that cgi shouldn't be used anymore.
PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
Earlier quoted context omitted.
These are web frameworks specifically but a good broad suite of examples: https://www.techempower.com/benchmarks/#section=data-r21&l=z... An amazingly fast specialized JS runtime solution [1][2] does indeed have the #1 spot on the most recent rounds, but full PHP frameworks hold spots #2 - 29 and then it's a mixture of PHP and JS all the way to #58 before we see the first other language (python, uvicorn) emerge. [1]…
You can also do some pretty "fun" things with PHP leveraging the opcache. I wrote what in my own personal biased benchmark was the fastest mustache template renderer by transpiling mustache to php files and then "compiling" them with apc [1]. Kind of a poor man's staging / partial evaluation optimizer. This is still running https://goldeneaglecoin.com/ whose framework (and HTML/CSS) is pretty much untouched since 201…
Earlier quoted context omitted.
> it's stateless by design (much easier to scale) I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. Most people scaled Drupal by puttin…
It might be much less efficient per request than other popular languages, but it's stateless design, does at least prevent developers from using local memory caches, which can prevent a number of problems from cropping up when scaling horizontally. With that said, I think the stateless nature of php is talked up too much. While not enforced by the nature of the language like php, writing stateless apps in other langu…
I of course value at least partial "stateless" (functional core / hexagonal architecture, event driven architecture) in any language, because they reduce complexity so much.
Earlier quoted context omitted.
> in the docs comment section. A classic boiled frog statement. __It's not undocumented, someone posted a comment about that bug...__ I will quietly place my face in my hands and weep to the memory of php coding I did 20 years ago. Seems the same nonsensical masochism is still going strong.
When I had to code in php I've written a css-rule for my browser to hide the user contributions to the docs, since they where often misleading if not plainly wrong. I remember no discernible border between 'official docs stop here' and 'user contributed opinions start here'.
Earlier quoted context omitted.
> in the docs comment section. A classic boiled frog statement. __It's not undocumented, someone posted a comment about that bug...__ I will quietly place my face in my hands and weep to the memory of php coding I did 20 years ago. Seems the same nonsensical masochism is still going strong.
When I had to code in php I've written a css-rule for my browser to hide the user contributions to the docs, since they where often misleading if not plainly wrong. I remember no discernible border between 'official docs stop here' and 'user contributed opinions start here'.
I do agree with the sentiment though that these unofficial notes should be taken with a grain of salt. In my experience, they have been more help than hindrance.
Earlier quoted context omitted.
They do. It's just that everyone seems to have collectively decided that cgi shouldn't be used anymore.
CGI has become "serverless" and it's hyped up to no end. The more things change, the more they stay the same.
I think the "the more things change, the more they stay the same" is a great thing, and something to very much be aware of and study. The move back and forth from backend state to frontend state to slim apps to fat apps has been going on since the 60ies, and is driven by ultimately hardware and networking costs.
The underlying patterns are all fairly well understood, which means that knowing both approaches and being aware that things are going to slosh back and forth heavily simplify long term design.
I haven't written these thoughts out, but in many ways the codebase (as in, how your files are organized) is largely independent of how your code is actually deployed and where it runs. If you are aware that some business logic might one day run in the frontend on the client device, and 4 years later might make more sense ot run in a lambda, that's something you can architect for.
Serverless / stateless is ultimately "functional programming". If you write your code as a side-effect free function, leveraging technologies like WASM, you can keep the same code, and deploy it frontend or backend or both or as a lambda or as a single node worker, and the code itself won't change. These are the things that next.js and vercel and edge computation leverage, but it is true in every codebase (embedded, desktop applications, etc...).