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 loads 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?
Application-as-a-Function Thinking
21–30 of 80 posts
Re: Application-as-a-Function Thinking
#22This 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
"in context", what does this mean?
Re: Application-as-a-Function Thinking
#23No.
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 obstacles to software simplicity, as there is a fundamental architectural mismatch here.
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.
Re: Application-as-a-Function Thinking
#24it seems like less sophisticated version of reactive paradigm to me, am I wrong?
I think you are right. If the response would be a promise or similar, it would become a reactive system. Disclaimer, I've avoided using reactive approaches as much as I can on the server side as it increases the complexity (and cognitive load) and makes diagnosing issues harder. This is my experience in the JVM world, I'm not sure how it is in other languages/platforms. [This article]( https://netflixtechblog.com/zuu…
Reactive.js is hellish too. Elm (basically The Article) dropped it too in favor of this simpler approach, but keeping some interesting parts.
Re: Application-as-a-Function Thinking
#25No. 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.
Re: Application-as-a-Function Thinking
#26No. 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.
Re: Application-as-a-Function Thinking
#27No. 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.destroyallsoftware.com/screencasts/catalog/funct...) that compelled TFA.
Re: Application-as-a-Function Thinking
#28No. 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…
Well you just described every report ever.
Re: Application-as-a-Function Thinking
#29Very 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.
Re: Application-as-a-Function Thinking
#30In 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…
What?