4 ms·

I really like two things about the Drakon docs I've perused: 1) They show how to draw a really clean flowchart, which is a bit of a lost art. I'm not a big fa

I really like two things about the Drakon docs I've perused: 1) They show how to draw a really clean flowchart, which is a bit of a lost art. I'm not a big fan of flowcharts - IME it seems like the biggest fans are, weirdly, mechanical engineers of a certain age - but hey 2) They show how to do a clean depiction of a state machine in flowchart format, which might come in handy for someone, somewhere https://drakonhub.com/files/lift.html https://drakonhub.com/files/lift.html Also, as a sort of meta-comment, I noticed that we have two comments from people doing workflow programming (presumably Sharepoint or similar, which I'm 100% sure gets no love or respect, but is super useful if you need it) who found these approaches useful. Workflow is a great use case for graphical programming; in a related vein, a hobby horse of an old friend is that a good graphical environment for devops would change the industry. The Russian wikipedia page (in auto-translate for me) has a ton more detail and history. I'm not going to a deep dive but I'm also not so sure about the claim that there's no history of aerospace use.

cyberax 2y ago
> 2) They show how to do a clean depiction of a state machine in flowchart format, which might come in handy for someone, somewhere https://drakonhub.com/files/lift.html https://drakonhub.com/files/lift.html This example triggers me in particular to no end, with statements like this: > DRAKON makes automata-based programming practical That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between floors", or "failed to transition to high speed from low speed", etc. Literally dozens of states with their own conditions and state machines. Attempting to display them all on a same diagram is useless. It's far better to represent them cleanly using a multi-level state diagram.
- layer8 2y ago
  DRAKON supports multi-level diagrams.
- buescher 2y ago
  >That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between floors", or "failed to transition to high speed from low speed", etc. Literally dozens of states with their own conditions and state machines. I feel your pain, I really do - the next step from oversimplification is "how hard could it be", right? (see my comment here https://news.ycombinator.com/item?id=33263261 https://news.ycombinator.com/item?id=33263261 where the responses mostly misunderstand me completely) Just about every state machine example that models a simplified embedded application suffers from the same issue, though. It's not unique to Drakon. I haven't used the full Harel statechart formalism or modeling tools in production, though I expect I eventually will, but I've worked on a project whose state table got about that big before it shipped. Yes, some hierarchy would help a lot. Next time. No, I wouldn't reach for a flowchart representation of a state machine as a first step in anything I can see myself doing. But even though flowcharts for programming pretty much went out with goto, they're still used to represent things like business processes and manufacturing processes (see Six Sigma, ISO 9001, etc). You will find a surprising number of non-programmer stakeholders that are comfortable with them. So I could see it being handy having the approach shown in that link in my back pocket in a bunch of cross-functional ways.

cyberax 2y ago

> 2) They show how to do a clean depiction of a state machine in flowchart format, which might come in handy for someone, somewhere https://drakonhub.com/files/lift.html https://drakonhub.com/files/lift.html This example triggers me in particular to no end, with statements like this: > DRAKON makes automata-based programming practical That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between floors", or "failed to transition to high speed from low speed", etc. Literally dozens of states with their own conditions and state machines. Attempting to display them all on a same diagram is useless. It's far better to represent them cleanly using a multi-level state diagram.

layer8 2y ago
DRAKON supports multi-level diagrams.
buescher 2y ago
>That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between floors", or "failed to transition to high speed from low speed", etc. Literally dozens of states with their own conditions and state machines. I feel your pain, I really do - the next step from oversimplification is "how hard could it be", right? (see my comment here https://news.ycombinator.com/item?id=33263261 https://news.ycombinator.com/item?id=33263261 where the responses mostly misunderstand me completely) Just about every state machine example that models a simplified embedded application suffers from the same issue, though. It's not unique to Drakon. I haven't used the full Harel statechart formalism or modeling tools in production, though I expect I eventually will, but I've worked on a project whose state table got about that big before it shipped. Yes, some hierarchy would help a lot. Next time. No, I wouldn't reach for a flowchart representation of a state machine as a first step in anything I can see myself doing. But even though flowcharts for programming pretty much went out with goto, they're still used to represent things like business processes and manufacturing processes (see Six Sigma, ISO 9001, etc). You will find a surprising number of non-programmer stakeholders that are comfortable with them. So I could see it being handy having the approach shown in that link in my back pocket in a bunch of cross-functional ways.