8 ms·

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 e

by treis 4y 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.

WJW 4y 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.
- treis 4y 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.
  - WJW 4y 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.
    - discreteevent 4y 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.
- mpweiher 4y 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...
  - WJW 4y 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 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.

by treis 4y ago

WJW 4y 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.

treis 4y 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.
- WJW 4y 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.
  - discreteevent 4y 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.
mpweiher 4y 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...
- WJW 4y 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 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.