6 ms·

Statecharts[1] predate UML, and became part of UML[2]. From the time of their invention to the present, people have devised systems for serializing (i.e. as da

Statecharts[1] predate UML, and became part of UML[2]. From the time of their invention to the present, people have devised systems for serializing (i.e. as data structures and code) statecharts and translating them to (or interpreting them as) executable programs[3]. While they may not be all the rage and take some discipline to learn and use effectively (what software tool/concept doesn't?), they can be a valuable tool for building reactive systems: A typical reactive system exhibits the following distinctive characteristics: It continuously interacts with its environment, using inputs and outputs that are either continuous in time or discrete. The inputs and outputs are often asynchronous, meaning that they may arrive or change values unpredictably at any point in time. This should be contrasted with transformational systems, in which the timing of the inputs and outputs is much more predictable. A transformational system repeatedly waits for all its inputs to arrive, carries out some processing, and outputs the results when the processing is done. It must be able to respond to interrupts, that is, high-priority events, even when it is busy doing something else. Its operation and reaction to inputs often reflects stringent time requirements. It has many possible operational scenarios, depending on the current mode of operation and the current values of its data as well as its past behavior. It is very often based on interacting processes that operate in parallel. Examples of reactive systems include on-line interactive systems, such as automatic teller machines (ATMs) and flight reservation systems; computer-embedded systems, such as avionics, automotive, and telecommunication systems; and control systems, such as chemical and manufacturing systems. — Harel and Politi, Modeling Reactive Systems with Statecharts: The STATEMATE Approach (1998) [4] [1] https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/res... [2] https://en.wikipedia.org/wiki/UML_state_machine https://en.wikipedia.org/wiki/UML_state_machine [3] https://userweb.cs.txstate.edu/~rp31/papersSP/stateMate.pdf https://userweb.cs.txstate.edu/~rp31/papersSP/stateMate.pdf [&] https://www.w3.org/TR/scxml/ https://www.w3.org/TR/scxml/ [&] https://github.com/jbeard4/SCION https://github.com/jbeard4/SCION [&] https://github.com/statelyai/xstate https://github.com/statelyai/xstate [&] https://www.rtsys.informatik.uni-kiel.de/en/archive/kieler https://www.rtsys.informatik.uni-kiel.de/en/archive/kieler [&] search the web and you'll find more [4] https://www.wisdom.weizmann.ac.il/~harel/reactive_systems.html https://www.wisdom.weizmann.ac.il/~harel/reactive_systems.ht...

calf 3y ago
I was asked to read Harel's paper as part of my thesis, I personally think this stuff is wonderful and foundational to computer science and computer engineering, researching issues like concurrency and system complexity. But I can see how industry programmers would find little direct use for it.
- michaelsbradley 3y ago
  And yet the motivation for Harel's paper was his being approached by his nation's avionics industry to develop some concrete tech to help the EE and software engineers work with confidence in their development of reactive systems, ones with lives on the line. Summary: https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.History.CACM.pdf https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.... Detailed account: https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.History.pdf https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.... One of the most interesting aspects of this story is the fact that the work was not done in an academic tower, inventing something and trying to push it down the throats of real-world engineers. It was done by going into the lion's den, working with the people in industry. This is something I would not hesitate to recommend to young researchers; in order to affect the real world, one must go there and roll up one’s sleeves. One secret is to try to get a handle on the thought processes of the engineers doing the real work and who will ultimately use these ideas and tools. In my case, they were the avionics engineers, and when I do biological modeling, they are biologists. If what you come up with does not jibe with how they think, they will not use it. It’s that simple.
  - calf 3y ago
    Yes, being practically-minded (engineering-centric) was an important aspect and intention of the StateCharts formalism. But the disconnect today I think is because demographically on hackernews aren't avionics engineers or biologists, they're more like FAANG / SV developers and as many have said here they just don't see the relevance (and call them architecture astronauts or whatever). An aerospace specialist would expend the effort to learn a theoretical formalism, but an iPhone developer, maybe not so much.

calf 3y ago

I was asked to read Harel's paper as part of my thesis, I personally think this stuff is wonderful and foundational to computer science and computer engineering, researching issues like concurrency and system complexity. But I can see how industry programmers would find little direct use for it.

michaelsbradley 3y ago
And yet the motivation for Harel's paper was his being approached by his nation's avionics industry to develop some concrete tech to help the EE and software engineers work with confidence in their development of reactive systems, ones with lives on the line. Summary: https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.History.CACM.pdf https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.... Detailed account: https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.History.pdf https://www.wisdom.weizmann.ac.il/~harel/papers/Statecharts.... One of the most interesting aspects of this story is the fact that the work was not done in an academic tower, inventing something and trying to push it down the throats of real-world engineers. It was done by going into the lion's den, working with the people in industry. This is something I would not hesitate to recommend to young researchers; in order to affect the real world, one must go there and roll up one’s sleeves. One secret is to try to get a handle on the thought processes of the engineers doing the real work and who will ultimately use these ideas and tools. In my case, they were the avionics engineers, and when I do biological modeling, they are biologists. If what you come up with does not jibe with how they think, they will not use it. It’s that simple.
- calf 3y ago
  Yes, being practically-minded (engineering-centric) was an important aspect and intention of the StateCharts formalism. But the disconnect today I think is because demographically on hackernews aren't avionics engineers or biologists, they're more like FAANG / SV developers and as many have said here they just don't see the relevance (and call them architecture astronauts or whatever). An aerospace specialist would expend the effort to learn a theoretical formalism, but an iPhone developer, maybe not so much.