[mike4921]

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 shame that Mathworks is essentially the only game in town though, and their software licenses are fairly expensive.

[01100011]

I'd rather have tools that can take code which implements a state machine and produce a statechart than go the other way around. There are a few tools which will go from statecharts to code and they've been around a while but never seemed to get very popular. I think dealing with a complex system as a statechart is potentially harder than dealing with code.

That said, my friend works on satellite software implemented with state machines. He was saying the high reliability of the system is mainly attributed to the requirement that systems be designed as statecharts first, which forces the designs to remain simple and analyzable.

[InitialLastName]

> the high reliability of the system is mainly attributed to the requirement that systems be designed as statecharts first, which forces the designs to remain simple and analyzable.

This can also be due to the fact that statecharts inherently require every transition and event to be mapped, which is more up-front work than most programmers do on their state machines. Need a feature that requires a new state? Instead of glomming it onto the code (and, in a complex codebase, probably missing one transition or another), you have to do the work of putting it into the state diagram and handling every transition into and out of that state (from every one of the connecting states in the graph). From there, you have a much more completely accounted list of the changes that have to be made to other states, in addition to a more complete list for testing the resulting code.

> dealing with a complex system as a statechart is potentially harder than dealing with code.

Yes, but it strikes me as harder in the same way that it's more difficult to get code to build when you have a strict linter and a strict static analysis tool in the pipeline; when reliability is worth a bit of developer-convenience-cost, we add procedures such that making changes takes more work at the beginning.

[chillingeffect]

>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 packages. I accept them for what they are, but they could be so much better!

[davidkpiano]

Working on this with XState! Let's talk.

[DoingIsLearning]

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 industry? I would imagine that MathWorks would have to go through some serious certification exercise specially for code generation?

[Yoofie]

Matlab/Simulink models are also heavily used in automotive ECUs. I'm not sure about space coding standards, but the code generated from Simulink can be, if selected, MISRA compliant and optimized for speed, accuracy, etc.

[jpembedded]

scxmlcc (http://scxmlcc.org) can translate state machines into high performance C++, and it is free.