Hacker News new | ask | show | jobs
by WJW 1341 days ago
Pretty much every web application backend is like this? For efficiency it skips recreating the entire OS process, but serving a single web request is exactly preparing some parameters, the app thinking for a bit and then coming back with a response.

Web app abstraction frameworks like Rack (Ruby), WAI (Haskell) and many others work exactly like that: they allow you to supply them with a function taking a HTTP request and returning a HTTP response, then run that for each incoming request. Nothing magical about that and it works extremely well in practice.
1 comments
treis 1341 days ago
You're skipping the part where Rails takes that Rack simplicity and does a whole lot of magic. There's a huge amount of state contained within Rails and then even more in the DB.

So yeah, we can say web servers work like functions if we cut out all the bits that don't and call them separate applications. But realistically they're not.

link
WJW 1341 days ago
Well of course, more complex applications are going to have more complex state. Rails does a lot more than most web frameworks, so it has a lot of extra state to keep track of. This doesn't make it any less a function, it's now just a function that takes in the internal state (including the db contents) as an input. That's exactly what the article describes.
link
treis 1340 days ago
> just a function that takes in the internal state (including the db contents) as an input

No Rails (or other) app has a function like this where the entire contents of the DB are passed in as a parameter.

And you can't handwave complex internal state as simply another parameter to a function because that complex state can change. That makes the function no longer solely dependent on the parameters passed in. Its behavior is dependent on the parameters passed in plus any changes made by other processes to the complex internal state.

link
WJW 1340 days ago
Maybe I've been spending too much time with the state monad, but that still sounds like a function to me. The fact that the DB contents get passed in implicitly as part of the context of a Rails app does not change that.
link
discreteevent 1340 days ago
There's a difference between a "function" that uses implicit contextual state and one that doesn't. We can call it a function with implicit context or we can call it an object or a service or a process. It doesn't really matter as long as we have some way of talking about it. Those other words have been in common use for a long time so it's probably more convenient to use them.
link
mpweiher 1340 days ago
That's exactly my point.

Sure, it is possible to model these things as functions, for example by "passing" the entire world as a "parameter". However, it is an extremely contrived modelling, basically you're hammering the square problem domain into the round function hole with the biggest hammer you can find until it "fits".

It is also possible to model these things as Turing machines, or NAND gates...

link
WJW 1340 days ago
The "app-as-function" is not at all contrived though, it has some very concrete applications that make use of the composability advantages that functions have. The [rack-test](https://github.com/rack/rack-test) gem (and similar languages) work exactly like this: they run the "app" part without the "web server" part to enable much easier testing. Rack middlewares similarly treat the enclosed app as just a function taking some specified input and returning some output value.
link