Is functional programming relevant to web development?
stackoverflow.com
stackoverflow.com
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.
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.
Unless we are talking 'bout a different framework, Seaside is Smalltalk.
In reality a lot of non-pure IO stuff tend to be the main part of what goes on in-between the request and the response in most web-apps...
Yes. This is why things like Rail's "flash" breaks the Internet... or at least your web app.
A resource can also be composed of parts of other resources. For instance, you can have an order resource which is composed of item resources that each have their own url.
I think the rails flash is usually used to send a user a message which will only be seen once on the very next request. Think of the message as a resource that isn't important enough to get it's own url, and every resource as a composite of the actual item they are looking for and an optional "message" resource. The message resource isn't important enough to store into permanent storage. It could be stored into the db backend and then loaded up on the next request, and then deleted once the user has seen it. In practice that's not practical so it's kept in memory.
I don't think it breaks the internet at all.
Consider: user submits form that loads slowly, application sets flash and slowly begins sending response. User gets bored and visits yoursite.com. Flash message appears on yoursite.com and does not appear on the page that is loaded after the form is submitted. Oops.
State breaks the internet.
Doesn't really seem like an oops to me.
State breaks the internet.
You submitted a form. That presumably changed the state of the resources at that url too.
The page should set the flash state when the state transition is done, not when it starts. It shouldn't matter if the user sees the message on the page after the form or from a different page altogether. What if every page had a history of all of the flash messages ever produced? You wouldn't call that "state" any more or less than the state of the objects you were trying to change in the form itself.
I think the part of this you actually don't like is that the following GET implicitly deletes the state (which is why we can optimize and store it in session rather than the db). But when the state is "messages unseen by the user" then it seems reasonable to me.
I think we can agree that any state where it matters what page they view the message on is probably not a good candidate for flash. I'm not even a rails programmer but I think there are better examples for the state-is-bad idea.
If you use git, it's like the HEAD reference. It's a pointer to the immutable commit. The reference itself is mutable.
At least that's my reason.
>Yahoo! Store was written by Paul Graham, who is a big Lisp advocate. He also wrote Hacker News, which is, effectively, a Reddit clone.
That being said, saying that different applications by same programmer doesn't count(as the SO comment implies) is ridiculous.
People often use Darcs as an example of why functional programming is a bad idea "for industry". But the irony is that Darcs has a state-heavy mutable data storage model. This is what makes it slow, not Haskell.
Compare Darcs to Git's completely immutable model, and you'll notice that you get fast Git clients even if you implement it in a language like Ruby.
The "takeaway" from functional programming is that immutability scales, no matter what syntax you implement the pure data structures in.
Since starting with Haskell many years ago, I don't think I've written any application that's been dependent on a mutable datastore. With nearly every business application requiring auditing and historical data retention, doing things right even gets you bullet-point features for free!
I definitely fall on the Erlang side, but (especially if you shrug off the fanatic outliers) the differences are actually quite minor.