I feel like the degenerate case is the happy path for basically any sorting algorithm: the computer doesn't need to do work. That'd make the leftmost skewer in the Wikipedia version of DRAKON quicksort perfectly fine.
As far as recursion is concerned, consider that DRAKON has exactly the expressiveness of assembly language. For environments where modified condition/decision coverage[0] is important (where analysis of branches at the object code level is commonplace), recursion is very likely undesirable, so not having a good way to express it is probably more a feature than a bug.
The only seemingly verifiable claim I can find to DRAKON's lineage in aerospace has to do with the Fregat upper stage[1] (though, I don't read Russian beyond an elementary school level, so I don't know what is actually said here), but given what I know of DO-178B and applicable NASA standards for safety-critical systems, it'd make sense to have DRAKON as part of the tooling.
> The only seemingly verifiable claim I can find to DRAKON's lineage in aerospace
I've been extremely annoyed by DRAKON cultists since 2005 (no, I'm not joking). They were basically claiming: "We have a tooling so powerful that it's used to produce ultra-reliable software for spacecraft, including Buran". When asked to show it, they replied that it's all super-secret. "Buran" is a Russian "Space Shuttle", btw.
Back then, my parents were still working in a factory that produced some of the "Buran" components. So I asked them to try to get me in touch with software developers who might have worked on anything related to "Buran". They got me in touch with a couple of developers responsible for parts of software in the ground monitoring system, but nobody heard anything about DRAKON. So it might have been used somewhere, but it certainly was not super-important.
Since then, DRAKON cultists have not produced anything significant worth of value. The largest project is, probably, the editor. And if you look at it, it's just a bunch of scripts where Drakon doesn't add much clarity.
You can also see that their tooling has zero practicality, it makes any sort of collaboration impossible. Drakon files are binary and can't be diffed sanely.
Forgive me, but I'm left scratching my head. I can't find where I mentioned any of this.
Buran's cancellation predates (given my limited command of Russian, what I think is) the first evidence of DRAKON's production use in the engineering process for avionics systems by almost a decade. Nowhere did I bring up that particular orbiter.
I'm also unsure where I wrote that DRAKON by itself is machine consumable. I'm only familiar with it as a pattern language for drawing diagrams, and that's the extent of my experience with it.
> I'm also unsure where I wrote that DRAKON by itself is machine consumable. I'm only familiar with it as a pattern language for drawing diagrams, and that's the extent of my experience with it.
The cultists claim that it IS a machine language. I don't mind it as a documentation language for simple algorithms, but it's not what they claim.
"The cultists claim that it IS a machine language." Cultists? I'm still left scratching my head as to how this is relevant to my comment.
I wrote about the Fregat upper stage, DRAKON's expressiveness as it relates to recursion with an example of an environment where it might be undesirable, and how the implementation of quicksort shown on Wikipedia is "perfectly fine."
In general, that's an apt description for DRAKON proponents. I interacted with them more than once.
And at this point, it's not even clear if DRAKON charts make sense even for their intended purpose: visual illustrations of simple algorithms. They are better than classic flow charts, but that's mostly because flow charts themselves are hopelessly bad.
Sequence diagrams are better to show interactions between agents, and good old state diagrams are far better structured to visualize state transitions.
I have a tightly-defined universe of discourse here, and you are operating almost completely outside it. Why is your engagement with my comment relevant beyond the connection to DRAKON?
So far, I've seen you write about cultists and Buran and, now, how sequence diagrams and state diagrams are superior. That final bit could admittedly make for interesting conversation, but I've heretofore not seen significant substantiation from you or, hell, any interrogation from you why I even use DRAKON.
Dare I say it, but I feel like I've been the target of your trauma response here, and I don't exactly appreciate it.
> The only seemingly verifiable claim I can find to DRAKON's lineage in aerospace has to do with the Fregat upper stage
It's not verifiable. It's once again co-authored by Drakon's author, and there is no other independent confirmation that any of his claims are true.
On the contrary, the main Drakon discussion forum has multiple threads and discussions trying and failing to even produce the simplest algorithms in Drakon. Much less anything as complex as aerospace requirements.
Drakon's author himself repeatedly fails to answer any questions about how to implement stuff in Drakon, and only answers with pseudo philosophical demagoguery.
The only notable software produced for Drakon is Drakon Editor https://drakon-editor.sourceforge.net/ which is essentially a UML editor with code concatenation
"The only notable software produced ... is ... essentially a UML editor ..." Yes, correct. It's a CASE tool, at least when you have a computer to assist with using it. For harder-hitting software applications, I never took much stock in using it as much more than a better way to diagram out the basic blocks when analyzing the disassembly of something, and I'm usually doing that by hand, without computer assistance.
More broadly, I never expected much from my CASE tools actually generating code for me: the scaffolding was possible, but any sophistication beyond that just never materialized. That ship sailed right around the turn of the millennium, and none of what DRAKON does innovates on that.
"It's not verifiable." Thanks. I always figured that a lot of this chaff was just marketing.
I'm pretty sure 60% of the reason is that it has a cool name :-P. The rest 40% is that at least the part you can easily see, like the comparison between arbitrary spaghetti flowcharts and much more tidy looking DRAKON flowcharts, do look convincing enough. Since 2-3 years now there is even a web-based editor you can play around with, which adds to its shareability.
Of course its mystique association with the USSR space program also helps despite supposedly all being classified (which, if anything, adds to the mystique), but IMO even without those, the cool name would do enough to be shared :-P.
Interesting 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.
I 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.
“Why is this on HN?” comments are often a mark of an intellectually interesting story…but not always of course.
As for quicksort in Drakon, if you need quicksort you might have an impedance mismatch between the application and language…might be knee deep in the Turing Tarpit. For example if you are building a real-time system, sorting to the degree quicksort seems like a good idea might suggest a design error.
I've enjoyed your critique of Drakon and its proponents so far, but it's very typical for real-time safety-critical systems to have coding standards in place that prohibit recursion; one example is MISRA.
1. There's no evidence that Drakon was used in aerospace industry beyond claims made by a single person: Drakon's author
2. Drakon is pushed as a generic programming tool despite: lacking generic programming facilities, lacking any tooling to actually produce working programs on any platform (except a single hobbyist implementation which is a UML editor with code concatenation: https://drakon-editor.sourceforge.net/drakon-erlang/silh.htm...)
This is such a straw man argument. The original comment claims that if a modelling tool cannot model something as simple as quick-sort, then it's useless in practice. BTW, there's nothing inherently "unsafe" about recursion, but that is completely not the point here.
Of course, there are plenty of things that are useful in practice that cannot model quicksort, or that would require you to implement stacks and recursion in awkward Turing-tarpit ways.
There's nothing inherently "unsafe" about a lot of things that guidelines for safety-critical firmware prohibit, either. More importantly, "safe" in the sense of "recursion is not inherently unsafe" is not the same thing at all as "appropriate for safety-critical applications". They can overlap, of course, or not.
The point is that you might not need recursion or might even actually want to avoid recursion in the domain claimed for Drakon. Whether it's actually been used in these kinds of applications or not, I have no special knowledge beyond having looked over the Wikipedia articles.
It is not being shared as a practical tool for people to quicksort their datasets in, it's an experimental tool made by a collapsed empire's defunct space program that seems to attract the interest of hobbyists.
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=quic...