[youerbt]

> So why hasn't it happened?

4. History. In those types of discussions, there are always "rational" arguments presented, but this one is missing.

> One with lots of persistent mutable state.

You mean like a database? I don't see a problem here. In fact, there is a group of programs large enough, that Haskell fits nicely, that it cannot be 3; REST/HTTP APIs. This is pretty much your data goes in, data goes out.

[AnimalMuppet]

> > One with lots of persistent mutable state.

> You mean like a database?

No, I mean like a routing switcher for a TV station. You have a set of inputs and a set of outputs, and you have various sources of control, and you have commands to switch outputs to different inputs. And when one source of control makes a change, you have to update all the other sources of control about the change, so that they have a current view of the world. The state of the current connections is the fundamental thing in the program - more even than controlling the hardware is.

[youerbt]

Thanks. This does sound like a state machine, though, but the devil is probably in the details. Yes, here Haskell is probably a bad choice, and something where direct memory manipulation is bread and butter should do better. Which is completely fine; Haskell is a high level language.

But in your example, PHP is also a bad choice, and alas, it dwarfs Haskell in popularity. I can't really think of where PHP is a great fit, but Haskell isn't.

[mrkeen]

Sounds like you want green threads, a concurrent runtime, and best-in-class synchronisation primitives.

[layer8]

HTTP APIs are just an interface. The application behind it can be almost anything.