Thanks. I love to see a description of that formalisation, if you ever get round to publishing it.
76 karma · joined March 9, 2016
I think you have correctly identified the important difference between the kind of applications I have been writing (mobile applications, which are relatively small and often have a good chunk of both side-effectful code and biz logic) and what your doing, which does not sound like it would have much to gain by spitting into a core & shell.
I have not much to offer you, having not worked on code such as you describe.
With this approach: 1. What downsides have you encountered? 2. How easy do you find it to onboard people? 3. Does Android do the same at your place?
I am assuming when a user interacts with one control button / dial / interaction it has a cascade effect on other controls / displays etc?
I am also assuming you already need to have a data structure representing the complete state of the system no?
There are multiple interesting aspects here, like are you / do you need to utilise complex state machines here? Just the subject of imperative vs functional state-machines is interesting and a small part of the wider approach.
Another interesting area is it depends on the language and execution environment you are operating in and how expensive operations over immutable data structures are.
Lots of questions!
In my experience the commonality found between client side mobile applications and reactive principles is essentially everything is a stream, and the UI subscribes to those streams.
The approach outlined in the post is similar in terms of the UI observes a (single) stream of data, which can just be a simple (State) -> Unit) as opposed to some reactive library stream primitive.
The approach outlines is different from all the "reactive" client side applications I have seen as there is no proliferation of stream primitives present throughout the codebase, which often seems to create complex code with very little if any user benefit.
I'm not sure what other elements you see in the post which also fall into the "reactive paradigm"?
Not targeted at the API crowd really no, more client side applications, but it seems similar principles have been applied in various places / frameworks as spoken about in other comments here.
> 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
Yes, I'm sure your right, but there are a huge number of people who are not web devs who have not been exposed to these fundamental principles and how they may apply in other operating environments :)
> For me the difficult part was where the side effects fit in and how they're processed, what you call "commands" and "command handler"
Do you mean difficult for you when designing, or difficult to understand in my post?
Your totally right, it's pretty similar conceptually to Elm in many ways, amazingly I only discovered Elm in the last 8 weeks or so after writing applications in this way for the last few years, maybe not surprisingly as I have been a mobile developer for 13 years and Elm is not big in the mobile space!
> Application is all about transitions of state, yes, but in context.
Like the other commentor says, it would be great to hear more about what you mean exactly by "in context" here.
> ... as a thought experiment it makes sense but it's not transferrable to the real world.
For the record, it's certainly not a thought experiment, I have been using this in the real world for a few years.
> Like take the log out action as an example...
The problem you outline with regards to intermediate UI states around the logout flow example is one of assumed responsibilities. If an application needs to show some specific transient UI when the application has moved between two states well, that's a UI concern and does not have to be modelled as part of the core application state. For example if you have a UI for an application which is required to show some jazzy animation when a user transitions from logged-in to logged-out that in no way needs to be part of the core application logic. The UI can just inspect the incoming state and conditionally when detecting a move from LoggedIn to LoggedOut trigger some UI animation / transient dialog / whatever.
One nice thought experiment / thought pump I find of value when dividing core application (~domain) and UI responsibilities is thinking about if you were to switch the UI from say a mobile framework (say Android/Compose) to a desktop terminal, what stuff stays the same and what stuff is display specific. In the above example you most likely would not want to show a jazzy animation on the terminal and therefore is display specific and should no be modelled in the core application logic. This is a nice simple thought process for dividing these responsibilities.
> 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?
No, a database would fall under IO and would make more sense to access behind a Command interface in this pattern, like most other side-effect interactions. This fits into the "functional core imperative shell" mindset referred to in the post.
> 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...
I am in no way experienced with BE caching layers, my experience is mostly client side mobile applications. However, my first approach for an in-memory DB cache would be to chuck that in front of the DB access behind the same abstraction, and also this would be behind the Command interface, again like all other side-effect interactions.
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.
> 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.
Turning off Bitcoin’s inflation funded security model - wishful thinking? https://www.onionfutures.com/essays/turning-off-bitcoins-inf...
The problem is, global warming is largely an issue _because_ of the "misunderstandings on behalf of others", so in this case, it is a real issue.
Totally understand that - but the article is written from the point of view that its already dead, which it of course is not, which will cause people to ignore the article. If I was diagnosed with a terminal illness today, I would not write to everyone I know saying I was dead, I would say I was dying.