[HN Gopher] A replica of Citizen Quartz watch based on Harel's p...
___________________________________________________________________
A replica of Citizen Quartz watch based on Harel's paper
introducing statecharts
Author : all2
Score : 136 points
Date : 2025-09-28 14:00 UTC (4 days ago)
(HTM) web link (andyjakubowski.github.io)
(TXT) w3m dump (andyjakubowski.github.io)
| ttd wrote:
| If you're fond of state machines as an abstraction for system
| design, I highly recommend reading the Harel statechart paper.
| It's well-written and understandable. And, it's truly a useful
| extension of the type of state machine diagrams software
| engineers typically produce.
| all2 wrote:
| I discovered the above implementation about the time I finished
| reading through the paper. I need to go back through and finish
| taking notes.
|
| I think there might be room to add `any` and `all` guards that
| take many guards as arguments.
|
| The other thing I've been pondering is the apparent similarity
| between ASTs and the sort of graph a statechart forms. If we
| compress state and chart into a single object, now you have
| states that can have parents and children (the semantics of
| what is an active state would vary with your node type, IE
| compound or parallel). Then your edges would the transitions
| between nodes.
|
| The semantics of the whole thing starts to look vaguely like
| there's a programming language that could emerge if the
| intermediate representation is hammered out well enough.
| TFortunato wrote:
| At Amazon Robotics we built a robot control system that
| executed state charts (described in an extended version of
| SCXML) in real-time for managing the core behaviors of the
| robot.
|
| To help people not have write the charts by hand, we built a
| DSL (originally in python, then in Kotlin), to author robot
| behaviors that then compiled down to SCXML. Conditions on
| guards were written in a tiny expression language we wrote,
| enabling you to look at various signals from the hardware and
| software at runtime and make decisions based off them.
|
| The nice part of this setup was that it opened up a path for
| doing more formal analysis on the behavior. E.g. you could
| easily find "terminal" states that you could enter but not
| leave. You can also imagine things like checking things like
| which states in a parallel or in concurrently running
| machines, aren't allowed to be active, and verifying there is
| no path in the state graph that allowed that to occur. There
| were other nice properties as well, like getting a graphical
| visualization of your program state "for free"
|
| It was definitely a more constrained model than a "full
| featured" programming language, but for our use case,
| controlling machines in a reliable way, it worked out very
| well!
| chermi wrote:
| Is there a modern reference implementation of statecharts? My
| understanding is that there's tons of offspring and they all
| kind of disagree. Same with regular FSM at least from limited
| understanding from this book
| https://ptolemy.berkeley.edu/books/leeseshia/.
|
| I'm a little worried the author (Lee) may have a particular PoV
| and perhaps this wasn't the best resource to learn from?
|
| I'm building an automated environmentally monitored +.
| controlled mushroom fruiting chamber. V1 I got by just with
| very basic state machines but I'm trying to take it up a notch
| in sophistication and do it the "right " way.
| all2 wrote:
| There is for JavaScript called XState. I think it is SCXML
| compliant .You might also take a look at qmuntal/stateless
| (not SCXML compliant), a golang module. It has rudimentary
| sub-state functionality.
|
| I'm in the process of writing a golang library, if you're
| interested in seeing some raw development (IE, I'm in the
| middle of designing dev UX, and the guts of the lib have yet
| to be implemented).
|
| You may also consider n8n for your uses. As workflow
| management goes, it is quite robust.
|
| For embedded work, I honestly don't know. I do know that
| golang can be transpiled into C (https://tinygo.org/) and
| tinygo + qmuntal/stateless might work really well for your
| use-case.
| chermi wrote:
| Thank you so much! For context, this for a "driver" running
| on a pi that controls actuators on an esp32 via MQTT. So
| the the most basics states just clones of the states
| (On/Off) on the esp32, while more complicated states would
| combine actions like fan + humidifier. I've written
| everything on the pi in python so far. But that was all V1
| and I'm starting over so maybe I'll try something new.
| all2 wrote:
| You might map out your functionality and see what you
| actually need in terms of programmatic functionality.
| LLMs are actually decent at creating the boilerplate if
| you know what you need.
|
| Here's an example I had Claude throw together for
| states/substates for a door with a lock
|
| https://mermaidchart.com/play?utm_source=mermaid_live_edi
| tor...
|
| Wow. That's a lot of link. Here's the raw chart:
| stateDiagram-v2 [*] --> Closed
| state Closed { [*] --> Locked
| Locked --> Unlocked: unlock / disengageBolt()
| Unlocked --> Locked: lock / engageBolt() }
| Closed --> Open: open [unlocked] / swing() Open
| --> Closed: close / checkSensors() note
| right of Closed Composite state with
| two substates end note note left
| of Open Simple state end note
| Locked: entry / engageBolt() Unlocked: entry /
| disengageBolt() Open: entry / startTimer()
| Open: exit / stopTimer()
|
| The syntax in the text labels is written the same way the
| Harel paper proposes: <State>: <entry/exit> / <action>()
| murki wrote:
| There's also https://github.com/cmars/statechart library
| built in rust
| neilv wrote:
| It's not available, but I once made a researchy
| Statechart->Java compiler. For the concurrency, it leaned on
| Java's green threads.
|
| Since then, I sometimes do manual implementations in code.
| For example, the Swift code of an iOS app I wrote has an
| ASCII art diagram of a hierarchical Statechart, for making
| the UI and NFC event handling solid (despite SwiftUI quirks
| and inconsistent docs at the time).
| RossBencina wrote:
| The ?modern reference specification is UML statecharts.
| However I'm under the impression that not all features are
| efficiently implementable. For example Miro Samek's book
| covers a subset for real-time systems: https://www.state-
| machine.com/psicc2 I highly recommend that book even if you
| end up rolling your own implementation.
| chermi wrote:
| Thanks! A quick glance at the book and it seems like it's
| focused on event-driven. Also seems kind of aligned with
| Lee's "actor model" stuff. I will read it more.
|
| I am ok-but-not-great programmer, hence trying this project
| to get better. It seems like I should learn UML proper and
| this book looks like a good way to start; my "architecture"
| diagrams are pretty laughable. I bounce between trying to
| be formal and learn what "proper architecture diagrams" are
| vs. thinking I'm spending way too much time not coding.
|
| I'm on a dirty and probably not-so-great hybrid of timer +
| event (mqtt) right now. I really want to try fully event-
| driven but it's a big change and I'm not very familiar with
| what it would entail. My original goal with this project
| was to implement MPC from scratch. V0 was mostly learning
| esp32 stuff and very basic bang-bang and timer control +
| FSMs that probably matched no formal specification. I've
| finished(or at least froze) the V1 microcontroller am
| starting the basic control/"driver" layer now, which is FSM
| based, so this reference is perfect timing. Thanks again!
| moolcool wrote:
| This is very cool, but why does the battery die so quickly?
| jsheard wrote:
| Probably to test the "low battery" part of the state machine
| without having to wait several years.
| tentahedronic wrote:
| Simply awesome. One thing I would suggest cleaning up is
| batteryPercentage which shows something ugly like
| 98.1000000000006 at least for me.
| klooney wrote:
| Delightful!
| RossBencina wrote:
| I always wanted to implement a graphical statechart editor
| specified in statecharts, or even implemented in executable
| statecharts.
| kloud wrote:
| Very cool! I created something similar for Casio F-91W. It also
| uses XState. The benefit of specifying a machine in XState, is
| that one can embed Stately editor to visualize the states and
| their transitions.
|
| https://github.com/dundalek/casio-f91w-fsm
| ripe wrote:
| Beautiful! I love the clean design of the page, too. I went
| through a period of obsession with the Harel paper, and your page
| is a nice summary of some of the key points!
| klaff wrote:
| Anyone else seeing how fast they can start/stop the stopwatch? I
| got .08 once but mostly .10-.12.
___________________________________________________________________
(page generated 2025-10-02 23:01 UTC)