
Is functional programming relevant to web development? - zeynel1
http://stackoverflow.com/questions/292033/is-functional-programming-relevant-to-web-development
======
DanielBMarkham
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.

------
jerf
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.

~~~
ohyes
"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."

Unless we are talking 'bout a different framework, Seaside is Smalltalk.

~~~
jerf
Oops, sorry, thinko. Too late to edit now.

------
narrator
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.

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

~~~
bobfunk
If it was a purely functional interaction, shouldn't the same request always
get the same response?

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...

~~~
jrockway
_If it was a purely functional interaction, shouldn't the same request always
get the same response?_

Yes. This is why things like Rail's "flash" breaks the Internet... or at least
your web app.

~~~
po
Each request should get the same "logical" response. There is nothing wrong
with the content varying with each request. A resource that represents "The
last 10 items processed" will always contain just that, even if the response
is different at the html level. This is why cache-invalidation is important.

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.

~~~
jrockway
_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.

~~~
po
_Flash message appears on yoursite.com and does not appear on the page that is
loaded after the form is submitted. Oops._

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.

------
rbanffy
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.

~~~
joevandyk
... but it's not popular? ...

~~~
rbanffy
I agree. It's not popular. But some would consider it as the next great thing.

------
loup-vaillant
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>

------
FluidDjango
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.

~~~
irahul
Strange, yes but it's kinda true. I saw somewhere Reddit's founder saying that
pg came to them and asked if a sub-reddit where he has the full control is
possible. When they said that model wasn't possible, he wrote hacker news.
That, and using it as an arc showcase.

That being said, saying that different applications by same programmer doesn't
count(as the SO comment implies) is ridiculous.

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

~~~
jrockway
Indeed. The language of implementation does not matter much, what matters is
what sort of data structure you use. When you can just read a piece of text
from a database, it makes little sense to create an opaque state-carrying
object dependent on the memory space of one process. news.arc is about as far
from "functional programming" as you can get.

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!

~~~
silentbicycle
You know what would knock the planet's socks flat on their asses? If the
Haskell and Erlang people got together.

I definitely fall on the Erlang side, but (especially if you shrug off the
fanatic outliers) the differences are actually quite minor.

~~~
bhiggins
Like strict vs. lazy evaluation by default...?

~~~
jrockway
This is not really an insurmountable issue. $ is the lazy function application
operator. $! is the strict function application operator. Use the one you mean
and it will all work out.

