Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Application-as-a-Function Thinking

doridori.github.io

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Application-as-a-Function Thinking

#41

Post by treis »

WJW wrote: post #36
mpweiher wrote: post #23

No. Applications are not functions. How many applications that you use on a daily basis work as follows: 1. You prepare some parameters 2. You start the application with those parameters. 3. The application goes away and thinks for a bit. 4. The application returns with a result and then exits. Trying to make actual applications and system fit into the function (or procedure) mold is, IMHO, one of the biggest obstacl…

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…

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.

Re: Application-as-a-Function Thinking

#42

Post by jjice »

AugustoCAS wrote: post #2

I couple of years ago I was lucky to use http4k, a server as a function web library for Kotlin. It was such a wonderful change compared to every other technologies available in both Java and Kotlin. It's simple. Testing becomes so much easier too, as one can instantiate a the whole web routing aspect, without having to bind it to a port and having to send real http requests. If strongly suggest people to take a look…

Sounds kind of like Go's HTTP handlers just being functions. Makes testing them very easy since you just call them with an http.ResponseWriter and a http.Request struct.

Re: Application-as-a-Function Thinking

#43

Post by treis »

kodroid wrote: post #40
mpweiher wrote: post #23

No. Applications are not functions. How many applications that you use on a daily basis work as follows: 1. You prepare some parameters 2. You start the application with those parameters. 3. The application goes away and thinks for a bit. 4. The application returns with a result and then exits. Trying to make actual applications and system fit into the function (or procedure) mold is, IMHO, one of the biggest obstacl…

Hey, thanks for your input. I blame myself for this misunderstanding as I wrote the article. I certainly am not suggesting that an application is a function, rather an application can be represented by single function as its core . There is an important distinction here as the production applications I have utilised this architecture in certainly do not literally behave as functions to the external user in the manner…

But this is the problem with basically every functional programming article that makes it's way to HN. As a thought experiment it makes sense but it's not transferrable to the real world.

Like take the log out action as an example. Mid request we are going to have to change the state from a user logged in to a user logged out. Otherwise when we render the home screen, as an example, they'll see the logged in version instead of the anonymous user one.

And realistically we want need a transition state to show a successfully logged out message since we do not want that message to show the next time they come. So the whole sequence for this simple action is:

Old State -> Intermediate State -> Render Response -> New State for the next request.

So we have to change state a couple times and pass that along.

And then how do we deal with stuff that's actually state. Like a database or whatever. Are we really passing that as a function parameter so that 10 calls deep can use it?

And what happens 6 months in when we want a caching layer? Do we go back and edit every single function to accept a Redis argument now?

Realistically, no. We have some sort of config or server object that we pass along. So we have an object that contains all of our server state that gets passed to most functions. How is that better than a single global variable holding that state accessible everywhere in the application?

Re: Application-as-a-Function Thinking

#44

Post by deepsun »

jjice wrote: post #42
AugustoCAS wrote: post #2

I couple of years ago I was lucky to use http4k, a server as a function web library for Kotlin. It was such a wonderful change compared to every other technologies available in both Java and Kotlin. It's simple. Testing becomes so much easier too, as one can instantiate a the whole web routing aspect, without having to bind it to a port and having to send real http requests. If strongly suggest people to take a look…

Sounds kind of like Go's HTTP handlers just being functions. Makes testing them very easy since you just call them with an http.ResponseWriter and a http.Request struct.

Not sure what's new here. Handlers were always functions in java (and other languages), even 20 years ago.

PP talks about general setup of the server in http4k (which I'm not a fan actually, because server setup is a very small thing done once. Just as a build file, I actually want it as long and verbose as possible).

Re: Application-as-a-Function Thinking

#45

Post by WJW »

treis wrote: post #41
WJW wrote: post #36

Earlier quoted context omitted.

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…

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.

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.

Re: Application-as-a-Function Thinking

#46

Post by [deleted] »

raydiatian wrote: post #6

> “Application as a Function” Forgive me if I’m oversimplifying, but isn’t this just “stateless servers” and “router-service separation” at its core? Maybe this isn’t targeted for the API crowd, but anybody who has spent even a few months learning modern client-server programming understands this, and web dev is pretty common these days…

[deleted]

Re: Application-as-a-Function Thinking

#47

Post by brap »

mpweiher wrote: post #32
brap wrote: post #26

Earlier quoted context omitted.

Did you read the post or just the title? It doesn't say that applications are functions.

TFA: Fundamentally an application can be written to have at it’s core, a single, stateless pure function, behold!

Yes, "at its core" being the center of the post. Are you ready to read it now?

Re: Application-as-a-Function Thinking

#48

Post by treis »

WJW wrote: post #45
treis wrote: post #41

Earlier quoted context omitted.

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.

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.

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

Re: Application-as-a-Function Thinking

#49

Post by carapace »

mpweiher wrote: post #23

No. Applications are not functions. How many applications that you use on a daily basis work as follows: 1. You prepare some parameters 2. You start the application with those parameters. 3. The application goes away and thinks for a bit. 4. The application returns with a result and then exits. Trying to make actual applications and system fit into the function (or procedure) mold is, IMHO, one of the biggest obstacl…

> How many applications that you use on a daily basis work as follows...

Most of them, but then I use the CLI a lot. E.g.:

    find  | grep   | xargs foo
Where "foo" is (of course) a kind of meta-parameter, both a parameter itself and a function/application.

- - - -

How do you mean, ALGOL isn't a general purpose language?

Re: Application-as-a-Function Thinking

#50

Post by hombre_fatal »

mpweiher wrote: post #31
hombre_fatal wrote: post #27

Earlier quoted context omitted.

Your numbered list seems like an appeal from incredulity based on the title rather than an interaction with the article. TFA basically describes Elm’s architecture https://guide.elm-lang.org/architecture/ which is one of the state of the art abstractions for building applications where you model state changes in a central function. Or watch Gary Bernhardt's "Functional core, imperative shell" talk ( https://www.destr…

I am familiar with both of these, as well as the article, thanks. Here is a quote from the article: Fundamentally an application can be written to have at it’s core, a single, stateless pure function, behold! And my point is that, yes, you can do that, but you shouldn't.

But your bulleted list is an incorrect entailment of what "a function at its core" means wrt OP, Elm, or Bernhardt's talk, so it seems more like you're reacting to your own reductio of what that quote could entail.

You haven't explained what is wrong with using a pure function to model state changes in an application. To do so, I think you'd also have to contend with the fact that a solution like Elm works quite well in practice.

Post reply on HN