Functional programming best matches web development because the web page is basically a static container that sends messages back and forth to a farm of servers. The server that gets the message may know nothing about what the web page is doing.

FP fits nicely because in FP you're always "threading the state" -- keeping everything you need around to make the program work. Functions can sit on a server, or on a million servers, and seamlessly process messages from clients. This is easily being done in the OOP-world, but on the FP side it's trivial, whereas with OOP there can be a lot of hoops to jump through.

WebSharper is very cool -- takes F# and makes it run as javascript. So you write one script module, annotating methods as running either on the client, server, or both, and then you just code as if all the methods were in the same spot. It figures out how to write the javascript and how the methods can talk to each other.

I'm also seeing some cool stuff with functional-reactive programming, which, if taken to its logical extreme, could rewrite large parts of the web server stack. In my opinion, because of the architectural nature of the web, in a lot of ways, functional code maps much more closely with web operations than OOP does.

Having said all of that, programming is programming, and if you know what you're doing, you can make things happen. Choice of languages and brands can be vastly overrated. The important part is knowing how to use the tools.

There are various interesting things in the various functional worlds in the very early phases of being interesting, but unless you are the sort of web programmer who routinely just programs up their own frameworks I couldn't really recommend any of them right now if you're not already a pretty good functional programmer and you're actively interested in participating in such early experiments.

Possible exceptions would include Seaside, which I've never used but has been around for a while and from what I can see has a genuinely different approach to web development that actually does exploit Scheme, and Erlyweb (and to some extent the Erlang frameworks in general), which naturally exploit being on the Erlang VM which has interesting consequences for certain types of web apps. I suspect neither would look particularly mature next to Ruby on Rails, but if you happen to have a need that matches those they may still be a win.

You can already do functional web programming with Scala/Lift. Be prepared for a real mind-bender of a web framework though. For instance, each form field specifies an in-line closure that gets called when the form is submitted. When you define an ajax button that is inserted into a form, clicking on that button invokes a server-side closure that's provided with the definition. There aren't any servlets, json parsing, ajax client library or anything like that in between. It's really quite nice. Just really really different.

Yes. The HTTP lifecycle is a perfect example of purely functional interaction. You get a request object. You produce a response object. Done.

The reason why functional programming is popular with web programming is that it explicits shared and changing state and allows the programmer to express the purely functional parts as pure functions. Pure functions have the advantage of being very simple to run in parallel - as they have no side-effects.

At least that's my reason.

Knowing that it's a good idea to avoid or isolate the assignment statement and other (side) effects¹, Id' say there's not many fields where functional programming is not relevant.

[1] http://www.loup-vaillant.fr/articles/assignment

Anyone find this comment (in a suggested answer) strange:

>Yahoo! Store was written by Paul Graham, who is a big Lisp advocate. He also wrote Hacker News, which is, effectively, a Reddit clone.

Just make sure you don't pointlessly store continuations when you don't need to, like on Hacker News.