I think that in tht moment when we start caring about rights on X more than about the X itself, we have a big problem.
There's an interesting thing. The thing is inaccessible because the site it's on is dead. The thing is known to be free-to-see. Why not cache it? One definitely should.
It's because both British and American Englishes (Is it correct to say "Englishes" heh?) are heavily written languages, so they tend to evolve much slowly and converge with their writing standard.
AAVE isn't so it evolves faster.
(btw, is it only me who hears something arrogant in "high German"?)
It needs to be fixed ASAP or we just won't have a next generation.
Paranoia is one of those brokenesses, there are much more.
The reason for it: bullshit is free, hence everyone scares parents to mine them for political power and other goodies.
But this breaks parenting more and more because people make wrong choices bases on wrong information.
Hibernate is horrible. But, object datastores aren't an option most often.
There are a lot of things wrong with SQL. For example, it's hard to do non-trivial queries because you can't say A = SELECT something FROM foo; SELECT another FROM bar WHERE field IN A.
Of course, you can make a view, but views are database structure, and you really really really don't want to change database structure in runtime.
So SQL sucks in some places.
In object-oriented programs they have no use of your "tuples". They just can't do anything useful of them, nor give them away (because that would violate code separation). So they have to turn your tuples into some objects (or other objects). Therefore, ORMs.
That's because native SQL apis in programming languages are horrible (JDBC, you are horrible).
So you want something to wrap your SQL with.
And then, you only have objects in your program, that's why it's called object oriented. So you often need to make objects from the result of your query, and manual bean fill-up is tedious. Therefore, ORMs.
On other hand, DBI is okay, so most Perl project don't use ORMs.
"most things become popular for very good reasons"
Sure. But those reasons are gone. Long gone. So please, wrap it out already.
"that is what a web server does"
Did. Most PHP apps don't use /some-article.php and /another-article.php with relevant PHP files under those names, that would be bizzare. There surely is A routing FRAMEWORK those days.
"One PHP file per page is also not true"
...if you're using A FRAMEWORK.
"There is also no 'default templating', I can pipe to, or make PHP calls from the command line"
So what? There's still default templating outside <? ?>
And that's what you use unless you've got A FRAMEWORK.
Do you see a pattern here? The pattern is that you didn't read my comment, you used regexes instead. Sadly.
But it still has 1000+ functions in the default namespace?
And every file still starts with <?
And if one of them doesn't, then your web app would fail epically because you were gzipping your output into your output stream (one and only one), and this extra space in one of files ruined your gzip.
To be fair, it's wonderful that complex PHP apps ever work. It's a complete surprise to me, I'd say they run-by-accident.
However I'd say he's directly responsible for the misery the most PHP development now is.
If he actually spent time reading about languages and designing his own, he would throw in function namespacing and function naming conventions and a good built-in abstraction for database access (with a strong bias against SQL injections and towards placeholders/variable binding from the day one), PHP would come out an okayish language and not an universal hate target.
There are some other blunders that he could just not make. And I'm not even dreaming about template system that makes sense now.
He didn't! Who the hell could do that if he wasn't going.
There's an interesting thing. The thing is inaccessible because the site it's on is dead. The thing is known to be free-to-see. Why not cache it? One definitely should.