21–29 of 29 posts
When you find yourself using a high-level language to emulate, badly, a below-machine-language-level state machine, you should recognize that you are in a state of sin, and ask where you have gone wrong in life.
Thus spake the Voice of Experience.
If you're not willing to develop all the boilerplate code to encode your states, transitions, etc. Boost has two libraries to offer : Boost Statechart and Meta State Machine. One of my favorite question on Stack Overflow compares both: https://stackoverflow.com/questions/4275602/boost-statechart... . As with most Boost libraries, you're in for some serious headache if you decide to use them (or is it just me?) but it…
Boost.SML (which is experimental) has garnered a lot of attention lately as a modern take on C++ state machines that can replace both of the options you raised. https://boost-experimental.github.io/sml/ Unfortunately I haven't seen any compelling real world usage of any of these libraries, and the documentation for SML leaves a lot to be desired.
Simulink, and specifically stateflow, is commonly used in the aerospace industry to graphically create state machines that can be autocoded into high performance C or C++ code. I use simulink and stateflow everyday to create flight control software. I feel like more software engineers should learn how to use graphical coding tools, as IMO it's so much easier to represent complex state machines graphically. It's a sha…
My previous first impression was that auto generated code was not very efficent and could easily create mangled unreadiable code. I assume this would be OK for prototyping something quickly but not for production grade applications.
From your understanding is Simulink + code generation a fairly common toolchain in industry? I would imagine that MathWorks would have to go through some serious certification exercise specially for code generation?
Every computer, and every program, is a state machine. We invented machine language, and increasingly higher-level languages, specifically to provide a better way to program than making raw state machines. When you find yourself using a high-level language to emulate, badly, a below-machine-language-level state machine, you should recognize that you are in a state of sin, and ask where you have gone wrong in life. Th…
Contrary to your baseless claims, programming languages were not developed to avoid writing state machines. They were developed to provide programmers with convenient abtractions that made them more productive and helped them implement what they wanted to implement. Back in the real world state machines, either generated from a DSL or hand-rolled by developers, are still the standard solution to implement a lot of mundane components such as network protocols, language parsers, user interfaces, and even control systems. We're talking about applications where the state changes depending on inputs in spite of where the control flow might be. If your experience hasn't taught you that then you should not be paying attention to its voice.
Simulink, and specifically stateflow, is commonly used in the aerospace industry to graphically create state machines that can be autocoded into high performance C or C++ code. I use simulink and stateflow everyday to create flight control software. I feel like more software engineers should learn how to use graphical coding tools, as IMO it's so much easier to represent complex state machines graphically. It's a sha…
Simulink, and specifically stateflow, is commonly used in the aerospace industry to graphically create state machines that can be autocoded into high performance C or C++ code. I use simulink and stateflow everyday to create flight control software. I feel like more software engineers should learn how to use graphical coding tools, as IMO it's so much easier to represent complex state machines graphically. It's a sha…
I've just started working in a safety critical field where Simulink model driven design is heavily used. My previous first impression was that auto generated code was not very efficent and could easily create mangled unreadiable code. I assume this would be OK for prototyping something quickly but not for production grade applications. From your understanding is Simulink + code generation a fairly common toolchain in…
Simulink, and specifically stateflow, is commonly used in the aerospace industry to graphically create state machines that can be autocoded into high performance C or C++ code. I use simulink and stateflow everyday to create flight control software. I feel like more software engineers should learn how to use graphical coding tools, as IMO it's so much easier to represent complex state machines graphically. It's a sha…
>Mathworks I used Simulink and Speedgoat (and LabView!) for many years. Oh how I long to create a startup that would improve on all of these dinosaur-like tools. Seriously if anyone wants to disrupt these entrenched, inertial companies, look me up. There are sooo many places to improve and you're right there's almost no competition. Trust me, I looked for it every few months when I ran into the limitations of these p…
Hierarchical state machine drawings are the way to go but it's generally not practical to build one on your own. That said, I wrote my own anyway: OOSMOS, the Object-Oriented State Machine Operating System (https://www.oosmos.com). It generates object oriented C from a state chart drawn with the open source drawing tool UMLet. OOSMOS is open source.