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.<p>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.<p>If strongly suggest people to take a look at it. It's not perfect, but it's a lot simpler than other frameworks and libraries. And it's a shift in some of the current mentality of using heavy frameworks (such as spring boot) which blow up anyone's cognitive load.<p><a href="https://github.com/http4k/http4k" rel="nofollow">https://github.com/http4k/http4k</a>
I like to think of it as "application-as-functional-specification".<p>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`.<p>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".<p>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.<p>From this spec you can then figure out what `State` needs to be, but this can be
done as a separate step not involving the domain expert but rather other
developers.<p>I learnt this from the Cleanroom software engineering people, they call the spec
without `State` a "black box spec", while the one with `State` is called a
"state box spec". (There's also a third step called "clear box spec" where they
break down the "state box spec" into functions.)<p>I've been playing around with the idea of designing a specification language
that lets you write "black box specs" together with some basic sanity checks of
those specs, because I think there's a lot of value in this sort of structure.<p>For example even if your application doesn't follow the
"application-as-function" pattern, you can still use your "state box spec" as an
oracle when doing property-based testing of your application.
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 <i>in context</i>. 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
How well does this approach scale for systems where the state is inherently large and complex? I write code that controls industrial machinery. There's just <i>loads</i> of different knobs and settings and modes that I can control with code, and a single production or test run will involve several heterogeneous machines, so the total state space is the cartesian product of all of those (not to mention the state of the physical widget they're all acting on, which we can only know imperfectly). I'm trying to imagine writing a data structure to represent all the different configurations the system can exist in, and it would need hundreds of different arguments just to instantiate it. The function to compute one state to another would be enormous and inscrutable. How do you deal with that?
No.<p>Applications are <i>not</i> functions.<p>How many applications that you use on a daily basis work as follows:<p>1. You prepare some parameters<p>2. You start the application with those parameters.<p>3. The application goes away and thinks for a bit.<p>4. The application returns with a result and then exits.<p>Trying to make actual applications and system fit into the function (or procedure) mold is, IMHO, one of the biggest obstacles to software simplicity, as there is a fundamental architectural mismatch here.<p>In the early days of computing, a lot of programs actually did work this way, which is why DSLs for algorithms (ALGOL) were appropriate, and probably where the idea originated that they are actually general purpose languages. Which they are not.
Very cool to see this! I've actually given this some thought a few years back when attempting to create (yet another) JS framework, and came up with something very similar to this! For me the difficult part was where the side effects fit in and how they're processed, what you call "commands" and "command handler". I didn't find an elegant solution to this and abandoned the idea early on, sparing the JS community.
Love this, thanks for sharing. This is fundamentally how our iOS application is modeled. We were highly inspired by Bernhardt’s talk and the Elm Architecture.<p>It has lead to a very modular and maintainable app that has been very easy to test without ridiculous mocking you usually see when needing to interact with object-oriented / imperative frameworks like Cocoa Touch.
> “Application as a Function”<p>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…
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.<p>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.<p>(Building this part myself: <a href="https://thestackreport.xyz/dashboards/tezos" rel="nofollow">https://thestackreport.xyz/dashboards/tezos</a>)