Why Programming in DRAKON is Cool
If someone woke me up in the middle of the night and asked, "Why do you program in DRAKON?", I could give the standard textbook answer.
DRAKON combines strictness and consistency with excellent readability. The language has several objective properties that make algorithms easier to understand: lines are not allowed to cross, diagram structure is predictable, and all DRAKON diagrams share a common visual style.
All of that is true, of course. But DRAKON is more than a collection of formal rules about box sizes, alignment, and diagram layout.
My encounter with DRAKON happened like this.
Back in 2003, I had the good fortune to work with an exceptionally skilled programmer. Let's call him K. He wasn't just talented. To be honest, he was a genius.
K. spent a lot of time teaching me modern software development. One day he said something that stuck with me:
"The problem with modern programming languages is that they are too textual. A program is a multidimensional entity. That's why programming needs a graphical representation."
At the time, I didn't think much of it. But over the years, the meaning of those words slowly began to sink in.
I could not see programs as deeply as K. did, but I started noticing some oddities in the traditional textual representation of code.
Take the humble if statement. When a program is small and contains only a single if, everything is fine.
But once branching starts happening in several stages, things get messy. Nested if statements are represented by increasing indentation. Indentation, by the way, is already a graphical element. It's just a very primitive one.
It forces the reader to mentally calculate where execution continues after diving deep into several layers of nested conditions.
Flowcharts solve this problem. You can simply follow an arrow from one box to the next.
Unfortunately, flowcharts have a problem of their own: drawing one that another person can easily understand is surprisingly difficult. Every flowchart tends to become a unique work of art. They belong in a museum, not in source code.
In technical terms, traditional flowcharts lack formality and consistency. Textual programming, on the other hand, has plenty of consistency.
And consistency matters more than beauty.
Eventually I gave up on graphical programming altogether. I turned my attention to other paradigms such as logic programming and functional programming.
Then came 2011.
I remembered reading years earlier about a Soviet programming language developed for the space industry. Curious, I searched the web and found DRAKON.
I followed a link and started reading an article by Vladimir Parondzhanov explaining the foundations of the language.
I hadn't even finished the article before I realized: This is it. This is what I've been looking for all these years. I felt a surge of excitement and energy.
Soon I became obsessed with the idea of creating my own DRAKON editor. Fortunately, Vladimir Parondzhanov himself noticed my work and began supporting me.
He taught me many of the finer points of the language. Just as importantly, he taught me how a DRAKON editor should be designed.
That is how DrakonTech, DrakonWidget, and several related projects came into existence.
As soon as I had a working editor and code generator, I started programming in DRAKON.
What's interesting is that programming in DRAKON no longer feels special to me. It feels natural. What feels unusual is going back to traditional text-based programming.
Whenever I have to write code the conventional way, I feel a certain discomfort. It's like driving a car for years and then being told to walk everywhere instead.
That's an emotional reaction rather than a logical argument.
To me, a text program feels like a collection of folded paper boats squeezed between the pages of a book. You want to pull them out, unfold them, and arrange them neatly on a table.
That's exactly what DRAKON does to algorithms. It untangles them and lays them out in front of you.
I've also heard other people describe their experiences with DRAKON.
One electronics engineer told me that DRAKON diagrams helped him find bugs in a very unusual way. He would simply look at the diagram, and suddenly he would know that something was wrong in a particular place.
Another developer explained his love of DRAKON differently.
Writing a traditional program, he said, feels like writing a school essay. Necessary perhaps, but not very exciting.
Programming in DRAKON feels more like playing a game. You're not writing software anymore. You're building a virtual world. Like Minecraft, but with a purpose.
And here's another opinion.
Science-fiction movies often show us the inside of alien spacecraft. The aliens never seem to operate their ships through plain text consoles. They always have enormous computers with beautiful visual interfaces.
DRAKON feels a little bit like that. Especially when you use a dark theme.
In recent years, powerful AI systems have changed programming dramatically.
Today you can simply say:
"Generate a C++ compiler for ARM."
The AI thinks for ten or fifteen seconds and produces something useful. Of course, reality is more complicated than that. But this is clearly the direction we are moving in.
At first glance, it seems like the problem of programming has been solved. The real difficulties begin when you need to create something genuinely new. Something that has never existed before.
The friendly conversation with the AI gradually turns into an argument. The vibe coder starts looking for clever ways to persuade a mechanical superintelligence to do exactly what is needed.
Little by little, a high-level request such as "make everything work nicely" turns into pseudocode:
X = A + BEven then, the advantages of AI are obvious. It catches many trivial mistakes and generates all the routine syntax for you: indentation, semicolons, braces, and so on.
Nobody really objects to using AI in that role. The problem is the trade-offs.
First, it can be slow. Sometimes you wait tens of seconds for a response.
Second, it is nondeterministic. The same prompt may produce one program in the morning and a different program in the evening. The bugs will be different too.
Third, it requires an internet connection. Not only on your side, but also on Claude's side. What happens if the connection drops?
And finally, AI can be expensive. A somewhat gloomy picture.
Fortunately, DRAKON exists. DRAKON sits somewhere between fully manual programming and fully automated programming.
Yes, it is much closer to the manual end of the spectrum. A modern AI can do far more than even the best DRAKON code generator.
Nevertheless, DRAKON code generation completely eliminates some of the most tedious parts of programming:
- indentation;
- braces;
- maintaining the overall structure of source files.
The challenge is not writing indentation and braces once. The challenge is keeping them correct every time you add, remove, copy, move, or paste code.
A DRAKON editor takes care of that automatically. Like an AI assistant, except fast and predictable.
- The editor inserts the necessary keywords.
- You don't need to track nesting levels.
- You cannot accidentally break the structure of a program by copying and pasting fragments.
And as an added bonus, the developers of large language models never get a chance to laugh at your code. Your code stays on your machine.
So here's another way to describe DRAKON:
DRAKON is fast, disciplined vibe coding with no cloud required.