Discussion on state machines

[NorthGuy]

Also, It may be worth the cost of using more resources for having more readable (understandable/maintainable) code. Depends.

You need to put this into perspective.

If you live in a country where everyone is sober, a statement that small quantity of alcohol is good for your health might be a great wisdom. However, in a country where everyone is totally and completely drunk all the time, the same statement would be just a lame excuse, a good advice would be to drink less.

With so much bloat everywhere (which, by the way, makes code less readable and less maintainable), a sensible advise would be to bloat less.

[tggzzz]

I used the C# reference as an example for how async/await works. Not suggesting to use it in a project with any set of requirements. Hobby stuff and Proof of Concept or just tinkering is another matter.

Although the idea and mechanism are language independent, a language integrated implementation does make it sooo much nicer.

In what way are they integrated into the language and why is that helpful?

In my experience having them (or their primitives) implemented as library classes/functions is sufficient.

[obiwanjacobi]

Also, It may be worth the cost of using more resources for having more readable (understandable/maintainable) code. Depends.

You need to put this into perspective.

If you live in a country where everyone is sober, a statement that small quantity of alcohol is good for your health might be a great wisdom. However, in a country where everyone is totally and completely drunk all the time, the same statement would be just a lame excuse, a good advice would be to drink less.

With so much bloat everywhere (which, by the way, makes code less readable and less maintainable), a sensible advise would be to bloat less.

Like I said it depends. First what you call bloat I call convenience (for instance) - so that's all a matter of opinion. What type of project, what skill-level the devs have, what legacy the company has etc. All I am saying is: think! Do not assume, do not discard ideas until you really understand them, try out new things (how will you grow?) and see if they fit. So speak of moderation in a drunk crowd and speak of experimenting in a sober crowd.
Using a higher level of abstract (lets assume more overhead) may be a valid choice when the problem is not in the real-time-ness of the solution but in the complexity of its logic (for instance).

(back to the topic)
Like the state-machines: the flow of actions can get from non-obvious to really confusing with if/then/else or switch/case implementations. Not separating the code under a case out into a function worsen the issue and may yield switch statements of several 100 lines.
I would not consider it bloat to have a mechanism/library/language feature to make that sort of code more readable even if it is not more performant (assuming no requirements exist that inhibit this choice).

----

I used the C# reference as an example for how async/await works. Not suggesting to use it in a project with any set of requirements. Hobby stuff and Proof of Concept or just tinkering is another matter.

Although the idea and mechanism are language independent, a language integrated implementation does make it sooo much nicer.

In what way are they integrated into the language and why is that helpful?

In my experience having them (or their primitives) implemented as library classes/functions is sufficient.

I would assume a language integrated feature works more bug-free than a library and the resulting syntax reads more natural.
"so much nicer" is beyond sufficient 

[tggzzz]

I used the C# reference as an example for how async/await works. Not suggesting to use it in a project with any set of requirements. Hobby stuff and Proof of Concept or just tinkering is another matter.

Although the idea and mechanism are language independent, a language integrated implementation does make it sooo much nicer.

In what way are they integrated into the language and why is that helpful?

In my experience having them (or their primitives) implemented as library classes/functions is sufficient.

I would assume a language integrated feature works more bug-free than a library and the resulting syntax reads more natural.
"so much nicer" is beyond sufficient 

I wouldn't assume that; my experience would lead me to believe the opposite.

Every time a "feature" is added to a language it will interact with all the other features - probably in unanticipated ways. Start by considering the interaction between templates and exceptions in C++, then have a look at home-grown DSLs (domain specific languages).

Contrast that with solid easily defined language plus libraries with a decent modern IDE.

[NorthGuy]

(back to the topic)
Like the state-machines: the flow of actions can get from non-obvious to really confusing with if/then/else or switch/case implementations. Not separating the code under a case out into a function worsen the issue and may yield switch statements of several 100 lines.
I would not consider it bloat to have a mechanism/library/language feature to make that sort of code more readable even if it is not more performant (assuming no requirements exist that inhibit this choice).

Excellent example.

Someone creates a state machine which is too big and unmanageable. I don't think the effect may be measured by the number of lines - few hundred lines is not that bad, depending on the way it is all organized, even few thousand may net be bad. On the other hand, 50 lines may be enough to create a mess. The case statement for a state machine is reminiscent of the Spaghetti code of old ages, and if you don't think well, your state machine can turn into a mess very quickly. Assume this happens - you created a state machine which is unmanageable (happened to me few times). This is already a bloat. The solution to this is to simplify the design - may be use different set of states, may be use hierarchy, may be avoid the state machine at all, may be re-think your data structure. At any rate, you need to throw away the mess, re-think it and re-do it in simpler, more efficient and more manageable way. This is a sad situation, but you should've thought of this before.

What people do instead? They try to preserve the mess while changing the form - using libraries, creating tables, may be using function pointers, may be switching to C++. These things may be useful, but it is possible to create/maintain a mess with any of these. Somehow, changing the algorithms and logical structure of "already working" solution looks like impossible task. On the other hand, using a library (or similar) which may magically organize the messy project looks easy. They try to preserve the worthless existing codebase as if it was their flash and blood. So, libraries get added, languages switched. This adds more bloat, but doesn't really clean the mess - may be ever so slightly.

We all know where it all moves - more libraries, RTOS, bigger MCU, FPGA - things keep snowballing - there's actually no end. And what is it all for? To perform a task which can be done on tiny little MCU with much simpler code and much less of development time? If you ask, they'll tell you that all this bloat simplifies (sic!) their work and make time-to-the-market way shorter and the extra-cost of the hardware doesn't matter. What else you expect them to say?

[SparkyFX]

It´s often that people don´t understand that their model just changed from one dimensional to multidimensional and try to compensate by adding a mess to the one dimensional state machine.

[tggzzz]

It´s often that people don´t understand that their model just changed from one dimensional to multidimensional and try to compensate by adding a mess to the one dimensional state machine.

What do you mean by "multidimensional" in this context? The two dimensions are "states" and "events"

It is often beneficial to split one large FSM into multiple smaller FSMs each with independent states and events between the smaller FSMs. But I wouldn't call that "multidimensional", I'd call it "good engineering taste"

[Howardlong]

It’s also resource hungry on low powered devices, not to mention adding even more indeterminism for real time systems.

But then, if you’re writing in C# under CLR, you won’t be doing deterministic real time systems, let alone on resource limited platforms.

I used the C# reference as an example for how async/await works. Not suggesting to use it in a project with any set of requirements. Hobby stuff and Proof of Concept or just tinkering is another matter.

Although the idea and mechanism are language independent, a language integrated implementation does make it sooo much nicer.

Also there is nothing wrong with abstraction or indeterminism (assuming you mean roughly the same as abstraction-ism with that).
C and C++ are abstractions or do you code in ASM? 
Any good library is an abstraction. I think you should be careful to chuck things on the "too expensive" (resources/learning curve/etc.) wagon and not consider it any further. It may not be more expensive that you trying to do it yourself.
Also, It may be worth the cost of using more resources for having more readable (understandable/maintainable) code. Depends.
Perhaps only a very small portion of the code needs to be close to the metal...?

It’s about using the right tool for the job. The time definite real time systems that I work on pretty much rule out anything that rely on JIT compilation or garbage collection. These tend to demand process responses well into the sub millisecond region, and event responses down to sub 10us and less, for example in my case digitally controlled SMPS and mixed signal RF.

At the UI, sure, whatever floats your boat, the event mechanism underlying most application UIs is nothing but a state machine. I will caveat that, though, and address the interminable end user frustration of random hangs while the runtime goes off and does some housekeeping.

As an aside, with my enterprise software hat on, I’ve still yet to have demonstrated anywhere where JIT compilation offers a real overall benefit, usually it’s the opposite, and it’s not unusual to have to force precompilation to improve response times.

[tggzzz]

The time definite real time systems that I work on pretty much rule out anything that rely on JIT compilation or garbage collection. These tend to demand process responses well into the sub millisecond region, and event responses down to sub 10us and less, for example in my case digitally controlled SMPS and mixed signal RF.

If you are worried about such hard real-time systems, then you also have to be aware of all the effects of all the various caches knocking around. Best if they don't exist or are turned off.

[Howardlong]

The time definite real time systems that I work on pretty much rule out anything that rely on JIT compilation or garbage collection. These tend to demand process responses well into the sub millisecond region, and event responses down to sub 10us and less, for example in my case digitally controlled SMPS and mixed signal RF.

If you are worried about such hard real-time systems, then you also have to be aware of all the effects of all the various caches knocking around. Best if they don't exist or are turned off.

Indeed, and “it depends”. Randomly performing JITs and garbage collection is very different in magnitude terms compared to L1 cache (as opposed to a disk backed virtual memory).

An end user can usually be expected to wait for a couple of hundred milliseconds for a response. A control loop for a switch mode power supply not so much.

JIT latency is why Microsoft realised in the relatively early days of .NET that they needed to provide NGEN to precompile code. There’s probably a similar thing in Java, but I’m not a recent aficionado.

[tggzzz]

The time definite real time systems that I work on pretty much rule out anything that rely on JIT compilation or garbage collection. These tend to demand process responses well into the sub millisecond region, and event responses down to sub 10us and less, for example in my case digitally controlled SMPS and mixed signal RF.

If you are worried about such hard real-time systems, then you also have to be aware of all the effects of all the various caches knocking around. Best if they don't exist or are turned off.

Indeed, and “it depends”. Randomly performing JITs and garbage collection is very different in magnitude terms compared to L1 cache (as opposed to a disk backed virtual memory).

An end user can usually be expected to wait for a couple of hundred milliseconds for a response. A control loop for a switch mode power supply not so much.

JIT latency is why Microsoft realised in the relatively early days of .NET that they needed to provide NGEN to precompile code. There’s probably a similar thing in Java, but I’m not a recent aficionado.

Java relevant GCs (there are many ) are remarkably good for "soft" realtime system running on multicore machines - certainly good enough for telecom applications. They are an order of magnitude better than almost all the program-specific GCs reinvented poorly by people that only know C/C++ - for a start, the Java GCs work reliably!

Anybody that uses Java for hard realtime systms needs re-educating. Unfortunately so do too many young C/C++ programmers.

I looked at C# once, just before it was released, Anders Hejlsberg the C# designer came and gave us a talk about it. The overwhelming response was "proprietary Java-lookalike without the advantage of dynamic compilation and with the disadvantage of having 'unsafe' bits". Nobody bothered to do anything with it, as far as I know.

I've never had reason to change that opinion, just as I never bothered to learn Delphi.

[SparkyFX]

What do you mean by "multidimensional" in this context? The two dimensions are "states" and "events"

It is often beneficial to split one large FSM into multiple smaller FSMs each with independent states and events between the smaller FSMs. But I wouldn't call that "multidimensional", I'd call it "good engineering taste"

I mean, if coming from a simple form, like a status only represented by a number (one dimension) and events that cause transition between states (jump on the number line, i would not call that a dimension), the transition itself takes some time, but there can only be one status active at any given time.

It then depends if the state machine is implemented in an absolute form (no memory of the last active state) or one that is relative to the last state it was in.

Imho only the latter form allows to add conditions that would lead to two mutually exclusive states (but based on the same event), you kind of add a layer on top of that and are not in a single dimension anymore.

You might be able to flatten it again, by extending the conditions to huge terms and segmenting the number line, which is often impractical and leads people to lose oversight and make errors.

[tggzzz]

I had forgotten what this discussion was about, since these refer to posts a week old. It would have helped if you included the context instead of removing it; this forum isn't stackexchange

Anyway, here's the full context:

It´s often that people don´t understand that their model just changed from one dimensional to multidimensional and try to compensate by adding a mess to the one dimensional state machine.

What do you mean by "multidimensional" in this context? The two dimensions are "states" and "events"

It is often beneficial to split one large FSM into multiple smaller FSMs each with independent states and events between the smaller FSMs. But I wouldn't call that "multidimensional", I'd call it "good engineering taste"

I mean, if coming from a simple form, like a status only represented by a number (one dimension) and events that cause transition between states (jump on the number line, i would not call that a dimension), the transition itself takes some time, but there can only be one status active at any given time.

Transitions are assumed to be instantaneous; if not then there is an intermediate state.

It then depends if the state machine is implemented in an absolute form (no memory of the last active state) or one that is relative to the last state it was in.

Imho only the latter form allows to add conditions that would lead to two mutually exclusive states (but based on the same event), you kind of add a layer on top of that and are not in a single dimension anymore.

You might be able to flatten it again, by extending the conditions to huge terms and segmenting the number line, which is often impractical and leads people to lose oversight and make errors.

That is either "spaghetti code" or some form of primitive neural network It isn't what is meant by a Finite State Machine!

That kind of nonsense can materialise if people are undisciplined. The best discipline is to represent the FSM in one of the many formal diagrams that have been designed over the decades, e.g. Harel StateCharts. Then the FSM can be translated, possibly automatically, into an executable language source code. XLSC. A decent executable language and use of design patterns will help prevent fools from directly modifying the XLSC in ways that are incompatible with a decent, predictable, comprehensible FSM.

But ultimately there is no way of making something foolproof, because fools are so damn ingenious.