[_dain_]

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?

[kodroid]

Hey, I can't say I have ever worked on such a project, it sounds like an interesting problem space.

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!

[_dain_]

>I am assuming when a user interacts with one control button / dial / interaction it has a cascade effect on other controls / displays etc?

Sometimes yes, it depends on the instrument. Some have user interaction, but most don't and are just controlled by the software I write. When I said "knobs" I didn't mean literal knobs, just all the different things these gizmos can do .. they come with thousand-page manuals.

OTOH sometimes shit breaks and you have to go in and send commands manually over telnet to unfuck it, or to gracefully shut down the operation without some delicate and expensive piece of equipment getting torn to pieces.

>I am also assuming you already need to have a data structure representing the complete state of the system no?

Nope, it's only feasible to keep track of the most salient variables. The code is very imperative: machine_a.do_this(), machine_b.do_that(), etc, sometimes for hundreds of lines. So the state changes in the background but it's not legible to us. The machines themselves probably have some representation of their own state in their firmware, but there isn't a single omniscient data structure for the whole system.

>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.

Yeah we use finite state machines to organize our code, but it's very coarse grained. Stuff like: LoadingState, ArmatureIsMovingState, TakingMeasurementState, etc. Each state in itself will issue many different commands to different machines. It isn't really formally defined where the boundaries are, it's just an informal way to orient ourselves so we can draw a flowchart and not lose our minds from the complexity, and so that there's some way of comparing similar-but-different programs (e.g. a run that measures current and a run that measures Young's modulus will both go in a TakingMeasurementState, but obviously the commands sent will be different).

It's not very amenable to automated unit testing ... I'm not sure what that would even mean in this context. The correct behavior you're testing against would just be ... a sequence of commands to the machines. Which is what the code does already. A unit test would be tautological.

>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.

We're using Python. I know that pyresistent exists, but honestly we could probably get away with doing naive deepcopies for every single operation and it wouldn't matter for performance. The runtime is completely dominated by the latency of waiting for the machines to do physical stuff (no concurrency for the machine-controller code thankfully; we're not insane). Immutable data structures don't really matter if we can't write down the entire state in the first place.

----

I guess the problem is that pretty much everything interesting that the code does is a side-effect. There are a few things here and there that can be factored out to pure functions and tested, but the overwhelming bulk is the "imperative shell". It's like one of those planets where the core has cooled and the crust has frozen down to comprise most of the total mass.

[kodroid]

Ha, I love that you mind went to that final analogy.

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.