[diggan]

I'm sorry, your "original" question doesn't seem to exist in your previous comments, so hard for me to answer it...

You get people to adopt technology or paradigms by explaining the benefits and drawbacks of adopting that set of technology/paradigm and then discussing it together with your team/s. Not sure why it would be different for Statecharts compared to any other paradigm?

What process is too hard for you now exactly, to describe states or something? You're already doing this implicitly when you write UI code with state. Statecharts only changes it from being implicit to being explicit. If you're having a hard time actually naming your states, you can use tools like https://sketch.systems/ to explore what you're building with a simple DSL, then implement it properly in the programming language of your choice.

[pixel_tracing]

Teams and technical debt go hand in hand. I don’t mean to sound snarky but this isn’t really practical for large teams to adopt at large companies.

1. writing code adds “debt” 2. Your solution is to now add state charts too which also adds “debt”

Where are these state charts tracked? Who maintains them? When product asks engineering to change code => you now also update state charts. Added technical debt.

If this is difficult for you to understand (the problem I’m describing is very common at large companies) I’m happy to expand more on it.

Thoughts?

[diggan]

I'm not sure if you're a developer or not, I'm just gonna assume you're not in order to hopefully be able to describe things better.

Yes, writing code can add debt, but not all code is debt. "Debty" code is code that can be better, but was needed in order to take shortcuts temporarily, probably in order to trade moving faster now against moving faster in the future. If you're taking shortcuts you're gonna have to fix it in the future, or deal with having to move slower/more careful because of it.

And yes, the solution to code debt is to go back and fix it properly. When it comes to UI programming, I'd argue that doing implicit state machines with conditionals scattered all over the place (which is the de facto standard today everywhere I look), is code debt, which can be fixed by REPLACING it with explicit Statecharts. It can also be fixed in other ways obviously, but besides the point here.

The developers would obviously be responsible for the code they write and the Statecharts are all handled in the same source control system your developers already use (typically Git today), so nothing really changes here.

And yes, when you figure out that you have to change the code to do something different, you're gonna have to ask developer to change the code. The same goes for updating Statecharts (that also exist in the code). If you have to change the states/transitions, you're gonna have to update the code that handles the states/transitions. This is the same no matter if you use Statecharts or not.

In the end, Statecharts is not a programming language itself, it's just a way of doing programming. Basically like how functional programming is a way of programming, or object oriented programming is one way, Statecharts is a different way where you're upfront with what states exist in the application.

[pixel_tracing]

Again you’ve described a paradigm like functional programming but failed to address my original question. I’ve been programming for over a decade now, and have seen this symptom over and over again. Someone sees shiny new paradigm => realizes is holy grail => fails to see how it fits into _actual_ working teams. My problem is that you are going to have a hard time selling this academic approach to _PRACTICAL_ teams doing every day work with every day deadlines and bottom line business dollars. Until you make this seamless and easy the extra work is just going to be _extra_ work which will be ignored.

I say this as a FAN of Statecharts and functional programming. I myself love this idea. I am looking and prodding people like you for SOLUTIONS to make teams adopt this.

So far you’ve failed to convince me on how to sell this to teams or make it easy to integrate.

[diggan]

> So far you’ve failed to convince me on how to sell this to teams or make it easy to integrate.

Yeah, because I'm not trying to convince you of anything. It's a tool in your toolbox, use it when you think it's advantageous, otherwise use your other tools. I couldn't care less of what you chose to do or how you "sell this to teams". I'm a developer who simply chooses the best tool for the job, sometimes that's Statecharts and sometimes it's something else. Also don't have any idea about what ideas are circling around in "Academia" as I'm far away from that ecosystem and only focus on shipping working products.

If you're looking for something "easy" in particular, then whatever you don't know is gonna be hard. Such is the life of a developer, where sometimes the simpler way is harder but worth it in the end. React was hard for people to grok in the beginning as well, but that doesn't mean it's bad, it just means people are not familiar with it. If you're just looking for easy solutions then yeah, feel free to stop improving and continue use the stuff you already know or is familiar to you.

So in the end, do what you will with the knowledge and experience I've shared with you, I have zero interest in selling you anything and I'm simply discussing stuff here on HN as I'm curious about things and want to have discussions with people who are also curious about things, but this discussion stopped being productive a long time ago.

[TeMPOraL]

> Who maintains them?

Developers, probably. But generally, whoever your team/company assigns this task to.

> When product asks engineering to change code => you now also update state charts. Added technical debt.

So is documentation. I would hope a team handles this somehow.

But if you approach it as a problem you actually want to solve, here's an idea: have the canonical statechart in code, and have the visual statechart be generated from that code. Benefits include: your visual/documentation charts are always synchronized with actual code; if somebody starts playing fast and loose with statecharts in code, the picture generator will break - if you treat this as a build error, you've just removed one common source of project rot.