> 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.
Plenty of jobs no matter what language have to be rewritten for many different reasons.
The fact is, and that is what you guys seem to have a problem accepting is that PHP is a perfectly reasonable tool for many reasons and for many situations.
Get over it. Make it as easy to get started with your preferred language rather than blaiming PHP.
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.
It's possible to connect to a production java server and hot swap code via eclipse. What's your point? Probbably not a good idea to do this for any real production system.
One of the big features of erlang is intelligent hotswapping for building robust telecom systems that never go down, but can be bug fixed/upgraded on the fly. Just because something is not commonly done with current tools doesn't mean its a bad idea, just that it is a bad idea with current tools.
My understanding is that built in java hot swapping is very limited, and indeed would be a bad idea to try hotswapping in production.
If the clojure repl brings us closer to the erlang world isn't that a good thing?
The type of code swapping you are doing with the repl, eg coding on the fly in the prod systems, and the type you are doing with erlang are completely different.
Erlang does have a much better deployment story than jvms as far as code swapping.
But AFAIK Clojure is compiling to bytecode and is under the same constraints as the JVM that it is hosted in.
> But AFAIK Clojure is compiling to bytecode and is under the same constraints as the JVM that it is hosted in.
This is true for certain features (protocols, records, and gen-class, which are easy to avoid for everything but high-performance bottlenecks and legacy interop), but vanilla Clojure functions are built around vars, which are specifically designed to support reloading.
edit: it's still primitive compared to Erlang, but it's miles beyond Java.
True good point. I still maintain that it's not a great idea in production and it really doesn't scale. I did stuff like this in single host servers in rails as well. Turns out to not be so repeatable and not a great idea in prod. Also isn't great if you bring down one node of prod or if you have a load that takes more than one box worth of processing.
I agree, but I would qualify that claim: it's not a great idea in production because the tooling to support doing it well doesn't exist, not necessarily because of limitations in the language.
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.
