ytdtty

You sound hysterical.

How many are founded by Native Americans?

How easy it is to find a webhotel and get started, how easy it integrates with HTML, JavaScript, CSS.

Good! We can see you clearly haven't tried using any of the many frameworks that easily integrate those things.

who besides a bunch of snobs and people who actually can't use it really cares?

The people who later have to re-write these garbage projects, for one. I guess you've never had a client with a failed PHP project who needed the thing fixed. Also, people who do things more complicated than geocities pages.

In what alternative universe is PHP a bad tool?

In the same universe where munging together logic and display code, or model and view code, is a bad idea. It's the same problem as using classic .ASP, except people are smart enough to not get all indignant when people point out how bad .asp was.

It is one of the easiest to get started with

That's nothing special. It's trivial to get started with dozens of web frameworks.

most documented

Most frameworks and languages are well documented. It's like you're bragging that you have the most well-vacuumed car seats, at a car rally.

best supported

Again, this is nothing special. Most frameworks have IRC channels and mailing lists.

for 90% of the things you see on the internet today.

90% of the things on the internet are so simple that you could easily use PHP for them, like blogs, simple forums, mostly static sites, etc. That doesn't necessarily make PHP a good tool. It just shows how you can easily do trivial tasks with mediocre tools.

You're right, you might need to spend 15 minutes reading a basic tutorial or cheat sheet.

That would be a good excuse for the apples to oranges comparison if people always ran production server code via the REPL.

Yes! Just look at the code required to serialize objects, send them between 2 computers, and deserialize them. You would need to do all of that stuff manually. Even with a library like AKKA, I don't think it's nearly as simple as it is in Erlang: 1 line to connect, 1 line to do the remote call.

In Erlang you can remote into servers, examine their message queues, update the running processes with new functions, etc. You can guess what that would take with those other languages.

You could roll your own supervisor process and have things automatically restarted when you lose connection to them in the other languages, but it's already baked into Erlang.