Excited to announce the current plan for StateML!

I think part of the challenge comes from the fact that a State Machine (SM) is simpler than a Turing Complete Machine (TCM). Using an SM inside a TCM (eg a UI Component) requires reasoning about both machines and the boundary between them at the same time.

“Our north stars for the StateML language” by @johnyanarella https://t.co/ojc1ytWgBu

Early this coming year, we are looking forward to sharing a formal specification, building out our tooling for multiple host languages, and opening up our codebase to the statechart community. 😄

Happy New Year! 🎉 It's been a year focused on language research and design, and all the rabbit holes we found along the way. After many iterations, we are now finalizing the StateML grammar and core tooling.

In the future we would love to open this digital garden up to the community, but we have a little more work to do before we get there! 🙂

For those interested in the technical aspects, we used #vitepress and @tailwindcss to quickly scaffold a static website that outputs only HTML and CSS. Nothing to special going on here (as it should be 😜). https://t.co/zbtaB2Jwd6

More interesting is the note titled "The symbolic boundary of statecharts; hidden between the visual formalism and executable schematic". It attempts to describe at a crutial design boundary that we stumbled upon! https://t.co/BoE8ay3CJc

The obligatory "hello world" post can be found here: https://t.co/uzvFM2W1NX

Happy to announce a digital garden/blog for StateML! 🎉 https://t.co/KhCGPpQahg We haven't publicized many details about our vision and what we are building so far so we are excited to reach a point where we want to start sharing more! 😄

The landing page for https://t.co/2iFiCc1tc0 is live! 🙌

@farzad_yz @StateML_org StateML! It's a new language. The core reference tooling is written in Typescript. But we're also working on Swift and Golang tooling too. And there's no limitation to what languages it can be used with.

@Zephraph @StateML_org A big part of the language design we worked on is how to enable the language to be extended without permission from us. We want to support the variations we see across libraries and languages, without requiring future changes to the language.

I’m really excited with where we have got to, and are going with this! 🚀 Every single word and character in the language has been dissected with @johnyanarella, @chrisshank23, and me. All the parts that made it through and into the language have a very good reason to be there.

Before the initial announcement we will also be working on building out additional tooling (please note these are all tenative): - Interpreters for JS/TS, Swift and Go - Exports for xstate, SCXML, ASL, ect. - Support for build tools like rollup/vite, ect.

Arrived to some general consensus!

Iterating on some logos 🧑‍🎨

In some lengthy @StateML_org language design discussions @chrisshank23, @johnyanarella and I have been getting very close to a final specification. In addition to targeting XState, Golang and others, Amazon States Language is a really interesting target.

A great listen! With some welcome challenges for lovers of statecharts: Is JSON really the best we can do as a DSL for building statecharts? How do we build a better story for composing statecharts together?