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

11–20 of 80 posts

Re: Application-as-a-Function Thinking

#11

Post by iddan »

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…

That idea sounds great. I think this kind of things really work well only in a dedicated DSL

Re: Application-as-a-Function Thinking

#12

Post by Huh1337 »

iddan wrote: post #10
Huh1337 wrote: post #9

Earlier quoted context omitted.

Elm was inspired by Flux/Redux, not the other way around.

Sorry no, the redux docs specifically mention Elm as an inspiration and previous art https://redux.js.org/understanding/history-and-design/prior-... Flux was before, but it’s not about application as a function

Hmm, you're right, Redux first appeared in 2015 and Elm in 2012. I was early adopter of both (didn't stick with Elm though) but I guess I only noticed Elm once it got popular. Thanks, my mistake!

Re: Application-as-a-Function Thinking

#13

Post by masklinn »

iddan wrote: post #11
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…

That idea sounds great. I think this kind of things really work well only in a dedicated DSL

It’s not that it works only in a dedicated DSL, it’s that if your language is too general it’s too easy to break out of the architecture when it’s a bother. So the pattern works, but you have to be religious about it, any breach will bring the entire thing down.

Hence much easier if the language itself precludes breaking out of the pattern.

Re: Application-as-a-Function Thinking

#14

Post by discodachshund »

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…

Scala's http4s is also such a lovely framework. Given the name similarity I don't know which came first

Re: Application-as-a-Function Thinking

#15

Post by Smaug123 »

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

Or the Unix vision of composable programs that do one thing and do it well. History repeats itself.

I think that's orthogonal. One can compose a mutable ball of mud out of a collection of components that individually do one thing well. A more apt analogy, though rather unbelievable (demonstrating how orthogonal the concepts are!), might be a Unix-style system where the entire environment were specified as inputs to every shell command. Nix takes steps towards this, but it's very different in style.

Re: Application-as-a-Function Thinking

#16

Post by dminuoso »

Huh1337 wrote: post #9
iddan wrote: post #4

This is basically introducing Elm (a.k.a the inspiration for Redux) to Android. At least for me this model doesn’t work. Application is all about transitions of state, yes, but in context . That’s why React’s model of managing multiple state points in different levels of the application tree makes so much more sense to me

Elm was inspired by Flux/Redux, not the other way around.

Neither is the case.

Elm semantics were originally loosely based on functional reactive programming in the sense of Conal Elliot, as per the thesis of its author.

Redux on the other hand is just imperative programming folks rediscovering that a state transition can be described as a pure function S -> S, with all the benefits that come along with it. This is as old as lambda calculus itself. Words like reducer are just red herrings.

Re: Application-as-a-Function Thinking

#17

Post by idlehand »

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…

The problem is that most Java developers like the cognitive complexity that Java EE frameworks entail. Those who like simplicity generally leave Java behind.

Re: Application-as-a-Function Thinking

#18

Post by kodroid »

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 to have access to previous inputs to `spec` invocations. What am I missing here?

> I think this is neat, because if you are developing the functional spec with a domain expert that doesn't know programming you don't wanna bother them with, for them, unnecessary bookkeeping details.

This sounds very similar to DDD (like as described as the DDD book at the end of the blog post).

> I learnt this from the Cleanroom software engineering people

At IBM direct, or are there any particular resources you can point to which you found useful?

Many thanks for the contribution.

Re: Application-as-a-Function Thinking

#19

Post by kodroid »

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…

Thanks for pointing this out, I had not heard of this one and yes sounds like it shares very similar ideals but for the BE.

Re: Application-as-a-Function Thinking

#20

Post by erwinh »

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-chain basically gives 'event logging' out of the box so all functions (i.e. contracts) on a chain can be monitored by any developer involved.

(Building this part myself: https://thestackreport.xyz/dashboards/tezos)

Post reply on HN