8 ms·
DRAKON
- instagraham 2y agoDocumentation here: https://drakonhub.com/en/drakon https://drakonhub.com/en/drakon
- deleted 2y ago[deleted]
- grumblepeet 2y agoAfter reading about this and the methodologies many years ago I implemented many of the precepts into my practice at the time (visual programming using a variety of workflow tools) and it really helped to prevent sprawl that is common with drag and drop workflow interfaces. It helps to enforce that discipline of not straying too far away from the desired path and handling exceptions. If it strays too far to the right then you know you need to look at things again and refactor. Worth reading.
- instagraham 2y agoHow different is something like this to say, a Jira workflow? I know there must be many like this but I think it might be particularly robust since it helped power the Buran launch and landing - which by all accounts was a bit of a miracle it all worked so well at first go.
- dang 2y agoRelated: The DRAKON Language - https://news.ycombinator.com/item?id=36021495 https://news.ycombinator.com/item?id=36021495 - May 2023 (38 comments) Why aren't there more visual programming languages? (An ode to DRAKON) - https://news.ycombinator.com/item?id=35712086 https://news.ycombinator.com/item?id=35712086 - April 2023 (2 comments) Ask HN: Anyone knows a flowchart programming better/more modern than DRAKON? - https://news.ycombinator.com/item?id=26137769 https://news.ycombinator.com/item?id=26137769 - Feb 2021 (1 comment) The Human Revolution in Understanding Programs [pdf] - https://news.ycombinator.com/item?id=19160248 https://news.ycombinator.com/item?id=19160248 - Feb 2019 (6 comments) Drakon: a visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=12638032 https://news.ycombinator.com/item?id=12638032 - Oct 2016 (39 comments) DRAKON – An algorithmic visual programming language - https://news.ycombinator.com/item?id=10100932 https://news.ycombinator.com/item?id=10100932 - Aug 2015 (48 comments) Drakon – A visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=6429283 https://news.ycombinator.com/item?id=6429283 - Sept 2013 (28 comments) Use DRAKON to Automatically Generate Code from Flowcharts - https://news.ycombinator.com/item?id=5497668 https://news.ycombinator.com/item?id=5497668 - April 2013 (1 comment)
- instagraham 2y agoOh apologies, I thought submissions here were akin to Reddit where it flags you if the same link has been submitted before. I'd Googled Drakon too without finding much discussion on it, but it didn't occur to me to search HN.
- pvg 2y agoThese links are just to help people interested in reading additional material and HN commentary - reposts are fine after a year, give or take and it's been more than a year since DRAKON's last.
- brudgers 2y agoSome topics are evergreen in part because their core principles ideas are deeply interesting and unique. In part because over time nobody can keep up with everything on HN and because there is a steady influx of new users by design. HN’s “Endless September” is a feature not a bug. Drakon can be new to you, still intellectually interesting to many people who have seen it before, and make people with a deep affinity for Drakon feel less alone.
- dang 2y agoPlease don't apologize, you got it exactly right! Just to add to what pvg and brudgers have pointed out: reposts are welcome on HN (especially after a year or so - https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html) and the "Related" links are just to point curious readers in related directions. I hope you'll definitely continue to post things you find interesting to HN.
- brudgers 2y agoFor clarity, dang is HN’s moderator.
- deleted 2y ago[deleted]
- jawns 2y agoI've used the (free) https://drakonhub.com https://drakonhub.com service to create Drakon diagrams, and I've been able to express some pretty sophisticated workflows in a clear, intuitive way. One of the things I love about it is that it is orderly by design. You've probably seen those scary flowcharts where arrows are pointing willy-nilly, criss-crossing each other, and there's very little cohesion. Drakon charts help avoid that by being relatively prescriptive about _where_ diagram components are placed. For instance, the happy path should form a skewer shape. The "Diagramming is different with DrakonHub" section of https://drakonhub.com https://drakonhub.com shows you the difference well.
- riedel 2y agoImpressive dogfooding > DrakonHub is written in DRAKON-JavaScript and DRAKON-Lua. https://github.com/stepan-mitkin/drakonhub https://github.com/stepan-mitkin/drakonhub
- miniwark 2y agoDrakonhub is nice and support also a few other flowcharts too. I highly recommand their very clear documentation to learn about Drakon.
- troupo 2y agoIt's amazing that this keeps being submitted to HN and keeps being featured. The people pushing this couldn't come up with a way to represent a simple quicksort in it [1]. Why does this keep appearing? https://forum.drakon.su/viewtopic.php?f=78&t=6124&hilit=quicksort&start=0 https://forum.drakon.su/viewtopic.php?f=78&t=6124&hilit=quic...
- echoangle 2y agoWhat’s wrong with this: https://upload.wikimedia.org/wikipedia/commons/2/26/Quicksort_DRAKON.png https://upload.wikimedia.org/wikipedia/commons/2/26/Quicksor...
- troupo 2y agoBy Drakon standards it doesn't follow the "one true way": - the main execution path must be the leftmost top-to-bottom "skewer" - there's no recurse (AFAIR) in Drakon, and there were heavy debates on how to express it properly
- cjohnson318 2y agoI use DRAKON, or a loose form of it, when I draw diagrams. I like to use a square action icon saying "GOTO <title>", where title is a rounded title icon that names a process or procedure. It's not perfect.
- troupo 2y agoYeah, that's what Wikipedia diagram does, too: it uses a lose/extended form
- echoangle 2y agoInteresting point about the recursion, that’s an issue. I think the reason is that it has aerospace heritage, I think explicit iteration control is important there. Having no good way to represent recursion is limiting for general purpose though.
- trhway 2y agoAnd for people who like such things, i raise a monster (dreamt on by an European telecommunications committee) that i fairly enjoyed working on 30+ years ago (you enjoy such things when you're young and new to the tech and it was the time when seemingly everybody was excited about diagramming/CASE/etc. :) - CCITT Z.100 SDL - diagramming language originally for the telecommunication systems, kind of an actor model with channels, messages, etc., all formally specified and diagrammed (less practical spiritual cousin of Erlang) https://guminski.net/pg/Z100.pdf https://guminski.net/pg/Z100.pdf
- morsch 2y agoThanks, I hate it.
- Archit3ch 2y agoOnce you start noticing this design language, you'll see it everywhere. For instance, in software/hardware audio processing you may load processing blocks. Typically they are arranged left-to-right, but MaxMSP can be top-to-bottom.
- deleted 2y ago[deleted]
- surfingdino 2y agoPersonally, I have always preferred https://en.wikipedia.org/wiki/Prograph https://en.wikipedia.org/wiki/Prograph
- DonaldFisk 2y agoDRAKON and Prograph are both visual languages, but otherwise quite different. DRAKON is a flowchart language, showing flow of control, so the order of execution of instructions is specified by the programmer, just like it is in imperative languages. Prograph is a dataflow language, in which instructions can execute as soon as they have all the data they need, so multiple instructions can execute simultaneously (or, on a single processor, in an arbitrary order). If you like Prograph, you might be interested in a similar language I've been developing: https://www.fmjlang.co.uk/fmj/tutorials/TOC.html https://www.fmjlang.co.uk/fmj/tutorials/TOC.html
- lovegrenoble 2y agohttps://drakon.su https://drakon.su
- cyberax 2y agoUgh. Them again. It's pretty interesting that they failed to produce any project of a reasonable size, after literally _decades_ of pushing DRAKON as the best tool ever for "reliable code".
- buescher 2y agoI 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 agoDRAKON 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.
- learn_more 2y agoIf you like diagrams that are also interactive via topological graph queries, See: https://schematix.com/video/depmap/ https://schematix.com/video/depmap/
- cdchn 2y agoKinda cool looking product, I like its perspective a lot especially the 'impact' view you can do. The physical view is something unique as well.
- 0xbadcafebee 2y agoWe really do live in a dark age. Rather than use WYSIWYGs to take advantage of better formatting and layout, all docs are in the crappiest format, Markdown. Rather than design GUIs using a visual language to quickly mock up interfaces, we manually code out command-line tools. We hand-craft text to style an interface, and have to constantly type, ship, view, edit, ship, view, between people with 3 different skillsets, and reinvent the wheel of application design in an application platform designed for document viewing. Rather than develop and adopt open standards for common tasks, everything has a custom interface, and all interfaces require custom integrations, so that nothing ever works with anything unless someone spends 100 hours tying it together with glue code. And rather than compose code visually in a program that validates it in real time (like CAD), we type out line by line, and use a slew of cobbled together tools and basic tests to check if what we typed has any glaring errors. With the most advanced technology in the history of the world, we've somehow made it more expensive, time-consuming, complicated and buggy to do things we did 20+ years ago.
- timlatim 2y agoText-based workflow has one significant advantage over GUI-based design: diffability. This enables patch-based collaboration: you can easily share your diff with others, review changes line-by-line, resolve conflicts between concurrent modifications, etc. Personally, I'm much more comfortable working on large documents in LaTeX compared to Word because I can see every change I make and easily revise/revert it. It's too easy to unintentionally hit some shortcut or button in a WYSIWYG editor that subtly changes the document and not realize it until much later, when the undo stack is useless.
- bionsystem 2y agoI've written quite a bit of powershell to automate stuff in Word in our docs (pdf generation, hyperlink creation and verification, etc), and I second this. It is awful to work with. I'd much rather have latex, markdown or anything else than WYSIWYG.
- 0xbadcafebee 2y agoWord can show you every change you made, as well as tools like Confluence (which is just a version-controlled WYSIWYG Wiki), and let you diff/revert individual changes. GUI design diffing is pretty simple too: you collapse a flowchart into a DAG and then diff the changes between two copies of the DAG. It's how you troubleshoot DAG-based software bugs. We could also just make a better way to diff GUI changes, if we tried. It's not nuclear physics... If people started using GUIs more, then they'd find new problems, sure, but then they'd just make solutions for them. There isn't a problem we can't solve. Except for the problem of changing a culture, like a culture of text. Culture is the hardest thing in the universe to change.
- jmartin2683 2y agoYou’d have to be really terrible at writing code for anything like this to be ‘easier’.