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

31–40 of 80 posts

Re: Application-as-a-Function Thinking

#31

Post by mpweiher »

hombre_fatal wrote: post #27
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…

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.

Re: Application-as-a-Function Thinking

#32

Post by mpweiher »

brap wrote: post #26
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…

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!

Re: Application-as-a-Function Thinking

#33

Post by mpweiher »

greymalik wrote: post #25
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… It is actually my full time job to support a suite of applications that do exactly this.

Yep, and these applications certainly do still exist. Scientific applications come to mind, probably also engineering support, and maybe financial modelling?

However, whereas they used to make up the overwhelming majority of programs, they are now minority, yet we still try to model all programs like this.

Which is obviously possible, after all we're doing it. But it's not a good idea.

Re: Application-as-a-Function Thinking

#34

Post by throw827474737 »

erwinh wrote: post #20

In a way for me smart contract blockchains are a good example of developers focussing on creating very efficient functional building blocks. A smart contract has 'functional' aspects in that it produces operations that update the state/storage. Developers are incentivised to think about direct cost due to gas/storage fees. Chain-level transaction standards create a base-level of interoperability. All of this being on…

Please just don't.. wtf

> event logging' out of the box so all functions (i.e. contracts) on a chain can be monitored by any developer involved

You cannot be serious..

Re: Application-as-a-Function Thinking

#35

Post by nine_k »

kodroid wrote: post #18
stevan wrote: post #8

I like to think of it as "application-as-functional-specification". A functional specification for a stateful system is a function from a list of all inputs to an output, i.e. `fun spec(inputs: List(Input)): Output`. This kind of specification doesn't need to specify `State` at all, as we can simply refer to previous inputs. E.g. imagine a counter system with the inputs `Increment`, `Reset`, and `Get`. The functional…

Hey, thanks for the input. > This kind of specification doesn't need to specify `State` at all, as we can simply refer to previous inputs. E.g. imagine a counter system with the inputs `Increment`, `Reset`, and `Get`. The functional spec for `Get` is "find the latest reset and then count the number of `Increment`s since then". I could be misunderstanding you, but this does not sound functional to me as `spec` seems t…

I suppose one should see "access to previous invocations" as function composition.

The counter's description is literally Church numbers.

Re: Application-as-a-Function Thinking

#36

Post by WJW »

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 and returning a HTTP response, then run that for each incoming request. Nothing magical about that and it works extremely well in practice.

Re: Application-as-a-Function Thinking

#37

Post by nine_k »

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…

Most application / API servers do pretty much that, they only to mot terminate the OS process.

Moat interactive applications can be seen similarly, they just do that in a loop, for every event coming from the user.

Re: Application-as-a-Function Thinking

#38

Post by epgui »

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.

Your point is not particularly convincing.

Re: Application-as-a-Function Thinking

#39

Post by arrow7000 »

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.

Why not?

Re: Application-as-a-Function Thinking

#40

Post by kodroid »

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 you describe, the user interaction is in no way affected by the architectural choice.

As others have eluded to this core pure function is really just a boundary between the external side-effect laden world (e.g. UI / network / sensors / OS etc) and the applications business / domain logic and NOT the boundary between the OS and the application which seems to be what you are describing.

I appreciate your input and the discussion it is provoking.

Post reply on HN