[HN Gopher] Statecharts: A visual formalism for complex systems ... ___________________________________________________________________ Statecharts: A visual formalism for complex systems [pdf] Author : sktrdie Score : 27 points Date : 2020-01-19 19:01 UTC (3 hours ago) (HTM) web link (pdf.sciencedirectassets.com) l%2FIAM1iiWxq0nVqv4uljwXAAVeEoe787L%2BEZ8mTCdbu6aefx4r0keotVqaBRfbd (TXT) w3m dump (pdf.sciencedirectassets.com) | clumsysmurf wrote: | A few times I've seen someone on HN bring up the idea of using | statecharts for UI implementation. Many years ago there was a | book around this idea, but I wasn't able to get a copy before it | became very rare. | | "Constructing the User Interface with Statecharts" | https://www.amazon.com/Constructing-User-Interface-Statechar... | | I've always wondered if statcharts were a powerful enough | abstraction to handle everything I needed, and would like to read | more about its specific application to implementing UIs. Does | anyone have any other references, books, etc? | enturn wrote: | I came across a javascript implementation [1] and HN discussion | from a year ago [2]. | | [1] https://github.com/davidkpiano/xstate | | [2] https://news.ycombinator.com/item?id=17805950 | rojoca wrote: | For js there are various implementations including this one: | https://xstate.js.org/docs/ | | Here is an article by the author of this library with some | justification for the appropriateness of statecharts in UI | construction: https://dev.to/davidkpiano/no-disabling-a-button- | is-not-app-... | sktrdie wrote: | This article is from 1985 and feels way ahead of its time. One of | the (sad) conclusions was: | | > (4) The future lies in visual languages and methodologies that, | with appropriate structuring elements, can exploit all the | obvious advantages of graphical man-machine interaction. | | > As to thesis (4), we believe that before long scientists and | engineers will be sitting in front of graphical workstations with | large (blackboard size?) displays of fantastic resolution, | carrying out their everyday technical and scientific chores. | | > The 'real' description of the object is usually given in some | textual, algebraic form, and the picture is there only to help | see things better, and to assist in comprehending the complexity | involved. Here we are suggesting that visual formalism should be | the name of the game; | | > Textual representations of these visual objects can be given, | but they are the aids (e.g., for users lacking graphical | equipment, or for applications requiring textual reports), and | not the other way around. | | Yet, 35 years later we are nowhere close to the man-machine | interaction the authors were suggesting. | davidkpiano wrote: | This is the paper (by David Harel) that initially inspired me to | create XState a few years ago. Here is a direct PDF link: | http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/reso... | | Many of the ideas carried over to UML, and statecharts are used | in many areas of software and hardware engineering today. They're | useful in many different aspects of modern development | (especially in user interfaces) because they strongly encourage | the developer to explicitly model the "finite states" of an | application, instead of writing ad-hoc logic everywhere in a | haphazard way. | | Like any technology choice, statecharts shouldn't be used for | everything, and should be used when modeling complex application | logic with (potentially hierarchical/orthogonal) finite states is | appropriate. | | Excellent guide to statecharts: https://statecharts.github.io | Community: https://spectrum.chat/statecharts Documentation for | XState: https://xstate.js.org/docs/ ___________________________________________________________________ (page generated 2020-01-19 23:00 UTC)