HN Academy

There is an edX course that covers state charts. It’s excellent, and Davis Harel is one of the co-instructors.

https://www.edx.org/course/programming-for-everyone-an-intro...

⬐ pixel_tracing

This isn’t really solving issues for most teams, how do you handle maintenance and tech debt of these state charts? And why only javascript example? You’re missing mobile

⬐ diggan

Statecharts are the solution to technical debt, not the source, as you're formalizing the possible states the user can be in, and "locking" it to that. You can even apply analysis to your codebase to figure out if you're actually covering all possible states and transitions.

If you take a look at the syllabus of the course, it's not about JavaScript, it's about the formalism and understanding the core concepts, without locking you to a particular technology. Whatever they are teaching in the course, you can apply to JavaScript/Swift as much as you can apply it to Desktop/Mobile.

Disclaimer: haven't actually taken the course, but planning to and I've read the description of it.

⬐ pixel_tracing

This isn’t answering my original question, how do you get teams to adopt this?

Until this process is made easy this will always just be a fever dream of fools in ivory towers

⬐ 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?

⬐ 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.

⬐ 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.

⬐ diggan

That's amazing, didn't know that, thanks a lot for sharing! Fitting that it starts today as well :)

⬐ bmitc

No problem! And as just a note, it starts everyday since it is a reoccurring self-paced course. But if I remember correctly, the instructors still answer questions.

I really enjoyed learning about the hierarchical state machines using statecharts.

There is an edX course by David Harel (the author of this paper) and Michal Gordon called Programming for Everyone – An Introduction to Visual Programming Languages. I highly recommend it for anyone dealing with state, whether you’re a programmer, designer, engineer, or manager.

https://www.edx.org/course/programming-for-everyone-an-intro...

I don't think there's an easy answer to this question. Software engineers still don't know how to exactly or even efficiently communicate with each other. It's still an evolving field and process. In general, it is helpful to understand software development as a sub-field of systems theory and design, so any book that discusses systems should help one better understand software development.

In general, I do also echo some of the other comments. If you are helping to design the app, you shouldn't necessarily need to understand the implementation details. In my experience, clients, whether they be external or internal or colleagues, getting too involved into what they think the implementation should be is usually a disaster. It puts pressure on the system to conform to how they think it should be, which is usually not necessarily how it should be, and it basically adds unnecessary constraints. The real constraints should be what the software should do and specifications on that, including how the software is intended to be maintained and extended.

Some thoughts on some specific courses and books that I think would be helpful to better understand the goals of software development and design and ways to think about it all:

Programming for Everyone - An Introduction to Visual Programming Languages: https://www.edx.org/course/programming-for-everyone-an-intro...

I think this course should be taken by managers, designers, and even software engineers. The primary result is that you'll come out of it knowing state charts, which are an extension to state machines, and this will be very useful for thinking about software and organizing what the software should do. Handling state is one of the primary problems in software, and you might notice that all of the various paradigms (OOP, functional, imperative, actors, etc.) in computer programming relate to the various ways people think about handling state in a computing system.

How to Code: Simple Data and Complex Data:

https://www.edx.org/course/how-to-code-simple-data

https://www.edx.org/course/how-to-code-complex-data

https://www.edx.org/micromasters/ubcx-software-development

These courses are taught by a designer of the Common Lisp language and based upon the excellent book How to Design Programs. It is essentially a language agnostic course that uses Racket to build up design paradigms that teaches you how to sort out your domain problem and designs into data and functions that operate on that data. The courses are part of a MicroMasters program, so if you really want to get into Java, that is taught in the follow-on courses.

Based upon your last comment, here are some book suggestions on how computers work:

Code: The Hidden Language of Computer Hardware and Software: https://www.amazon.com/Code-Language-Computer-Hardware-Softw...

The Pattern On The Stone: The Simple Ideas That Make Computers Work: https://www.amazon.com/Pattern-Stone-Computers-Science-Maste...

But How Do It Know? - The Basic Principles of Computers for Everyone: https://www.amazon.com/But-How-Know-Principles-Computers/dp/...

The Elements of Computing Systems: Building a Modern Computer from First Principles: https://www.amazon.com/Elements-Computing-Systems-Building-P...