I love it. Visually you can immediately see what the inputs are,what the functions are and what the outputs are..just by the color code. It's brilliant
Hi Мне нравится использовать Дракон схемы для составления документации, ТехЗадания и т.д. где наглядность и ясность для понимания исключительно важны. В документации используются декларативные, высокоуровневые конструкции. Конкретно в этом видео упор на генерацию кода и низкоуровневое программирование -- здесь Дракон схемы, на мой взгляд, менее применимы. Это первое И второе -- вопрос, можно ли вставлять Дракон схемы в электронную документацию не через PNG картинки, а скриптами? Т.е. есть ли отдельный модуль на JavaScript который генерирует Дракон схему из кода (текста Дракон схемы) ? Например как Mermaid JS, который я использую в документации в настоящий момент
Looks pretty neat, even if I don't use it. Probably I would have a couple of rework suggestions (should I use it on my own). PS. What is the soundtrack, please? :)
А как ты хочешь реализовать сам процесс программирования? За счёт составления блоков как в google blockly? Только это блоки получаются буду внутри дракон схемы?
Does the Drakon IDE have a feature, to load a source code file in a programming language such as C, C++, or D, and generate a graph based on that source code file? Such a feature would be useful for understanding code that I didn't write. I work as a software engineer in a large company, where many different people are working on a single huge project that has been in development for almost 20 years now. Many functions are looking like spaghetti code. Having the ability to load in a source code file into Drakon IDE, and have it generate a diagram, or a series of diagrams representing that source code file would be very useful for me to understand what the code is doing. Because I am having trouble looking at the code that I didn't write and figuring out what it does. If such a feature doesn't exist yet, can the developers of Drakon IDE please add such a feature? Spasibo.
Personally I like the old statement editor better than the new one. It is true that a whole bunch of convoluted if statements, switch statements, and for loops, such as those representing a state machine for example, is very hard to read. So we use the Drakon IDE for visualizing the control flow of the program, to know what happens under what conditions and in what order. But I think that the individual statements, assignments, and function calls should be kept as they are in the code. They should not be deconstructed further into multicolored boxes. That makes the code harder to read and understand. The individual function calls are atomic elements, they can be understood in the O(1) time for the brain. Whereas the control flow of nested loops and branching statements takes O(N) time to understand. With a source code visualization tool such as Drakon IDE we can lower the time necessary to understand the logic of a function into O(1). But changing the ways that the function calls get represented only makes the code harder to read. You get diminishing returns that way, because the multicolored boxes are unfamiliar and unintuitive for me, and I think the majority of programmers also. Function calls have as information not only the name of the function itself, and what it's arguments are, but also the positional order of the arguments, the operator precedence of subexpressions grouped by parentheses, also have their own information that is useful for the programmer. In this proposal for a new statement editor, you lose all of that information about a function call by replacing the code with multicolored boxes. You lost the context of the positional order of the arguments, and any operators and subexpressions within that same statement. These are diminishing returns. You attempt to simplify, but you lost a ton of valuable information in the process. The editor is perfect already, no need to change it. In my humble opinion I think that these are bad changes.
Популяризация должна быть через свободное распространение. как UML. Нужны интеграции в разные приложения в виде наборов всех фигур и компонентов отображения диаграмм. Для меня самое главное что ДРАКОН был придуман раньше, чем UML.
Как тебе сказать... Графические методы составления кода хороши тем, что они понятны всем, но код обычно на столько длинный, что проще пересмотреть его в общепринятой концепции, чем разглядывать нагромождение геометрических фигур.😁 (Хотя, наверно, есть иные мнения - не спорю😁)
I know I am two years late to the party but I dislike that the arguments aren't grouped together. In the parse url example, I have no idea what true is or relates to. I don't really care that one is a function call and one is a literal in grouping, I want to see a track for arguments together as they resolve into the result returned
I love it. Visually you can immediately see what the inputs are,what the functions are and what the outputs are..just by the color code. It's brilliant
Don't play with GoTo, master Yoda 😁
Looks good to me, also makes the blocks language independent; which is a great plus.
Yes! That would work very well I think, great idea.
If your code is short 😁
I think current implementation is good enough.. Coders still love to see their codes
Hmm...🤔
So that's graphems for functions... I like the idea. I think it needs to be implemented, but the specific design should be more though out.
It’s a very interesting implementation:
Hi Мне нравится использовать Дракон схемы для составления документации, ТехЗадания и т.д. где наглядность и ясность для понимания исключительно важны. В документации используются декларативные, высокоуровневые конструкции. Конкретно в этом видео упор на генерацию кода и низкоуровневое программирование -- здесь Дракон схемы, на мой взгляд, менее применимы. Это первое
И второе -- вопрос, можно ли вставлять Дракон схемы в электронную документацию не через PNG картинки, а скриптами? Т.е. есть ли отдельный модуль на JavaScript который генерирует Дракон схему из кода (текста Дракон схемы) ? Например как Mermaid JS, который я использую в документации в настоящий момент
Ладно, скажи хоть чего ты достиг за прошедшие 3 года впустую.
Looks pretty neat, even if I don't use it. Probably I would have a couple of rework suggestions (should I use it on my own).
PS. What is the soundtrack, please? :)
А как ты хочешь реализовать сам процесс программирования? За счёт составления блоков как в google blockly? Только это блоки получаются буду внутри дракон схемы?
А там что, компилятор отсутствует?
I think, it is a very good idea! Basically the same approach is used in the Yaml compared to Jason and XML and in Huml for example compared to HTML.
Very interesting. I shared it with my colleague, who is not a programmer. He also understood and liked it.
Шикарно Бро, за этим будущее..... А под Python также возможно делать такие визуальные блоки?
Да, на Питоне и сделай.
Лень? Мне тоже.😁
Does the Drakon IDE have a feature, to load a source code file in a programming language such as C, C++, or D, and generate a graph based on that source code file? Such a feature would be useful for understanding code that I didn't write. I work as a software engineer in a large company, where many different people are working on a single huge project that has been in development for almost 20 years now. Many functions are looking like spaghetti code. Having the ability to load in a source code file into Drakon IDE, and have it generate a diagram, or a series of diagrams representing that source code file would be very useful for me to understand what the code is doing. Because I am having trouble looking at the code that I didn't write and figuring out what it does. If such a feature doesn't exist yet, can the developers of Drakon IDE please add such a feature? Spasibo.
Personally I like the old statement editor better than the new one. It is true that a whole bunch of convoluted if statements, switch statements, and for loops, such as those representing a state machine for example, is very hard to read. So we use the Drakon IDE for visualizing the control flow of the program, to know what happens under what conditions and in what order. But I think that the individual statements, assignments, and function calls should be kept as they are in the code. They should not be deconstructed further into multicolored boxes. That makes the code harder to read and understand. The individual function calls are atomic elements, they can be understood in the O(1) time for the brain. Whereas the control flow of nested loops and branching statements takes O(N) time to understand. With a source code visualization tool such as Drakon IDE we can lower the time necessary to understand the logic of a function into O(1). But changing the ways that the function calls get represented only makes the code harder to read. You get diminishing returns that way, because the multicolored boxes are unfamiliar and unintuitive for me, and I think the majority of programmers also. Function calls have as information not only the name of the function itself, and what it's arguments are, but also the positional order of the arguments, the operator precedence of subexpressions grouped by parentheses, also have their own information that is useful for the programmer. In this proposal for a new statement editor, you lose all of that information about a function call by replacing the code with multicolored boxes. You lost the context of the positional order of the arguments, and any operators and subexpressions within that same statement. These are diminishing returns. You attempt to simplify, but you lost a ton of valuable information in the process. The editor is perfect already, no need to change it. In my humble opinion I think that these are bad changes.
Когда писали слово "ламер", наверно имели в виду тебя.
Да/нет?😁
Ну скажи, скажи, успел разбогатеть?🙌
Популяризация должна быть через свободное распространение. как UML. Нужны интеграции в разные приложения в виде наборов всех фигур и компонентов отображения диаграмм.
Для меня самое главное что ДРАКОН был придуман раньше, чем UML.
Как тебе сказать... Графические методы составления кода хороши тем, что они понятны всем, но код обычно на столько длинный, что проще пересмотреть его в общепринятой концепции, чем разглядывать нагромождение геометрических фигур.😁
(Хотя, наверно, есть иные мнения - не спорю😁)
I know I am two years late to the party but I dislike that the arguments aren't grouped together. In the parse url example, I have no idea what true is or relates to. I don't really care that one is a function call and one is a literal in grouping, I want to see a track for arguments together as they resolve into the result returned
This method is good for robotic technology (primitive systems, I think) without intellect
@@ЧенЛи-ф4ш in what way?
how dependecies work? And congratulations for this amazing tool. Me and some friends starting studing in Drakon.
And?.😁
Two years later...
Very good idea. You should add python langage too. And how to implement other langage ( I work with modelica as well)
And?.😁
What a code?
Say, you're a rich man this day
or the time is lost like your youth?
It is implemented yet?
Приветствую, как дела с этим проектом жду не дождусь опробывать? 👍
Ну, и?.😁
Или ещё три года не прошло?
Наверно уже input, and, print, null писать научился?
I think it's fantastic
would make my work a lot easier
I currently have no idea how to improve this 😄
I just got feature requests haha
besides that, thank you for your work on the drakon editor
Приветствую!
Попробовал drakon editor для винды и он отдичается от вэб версии на drakonhub... Веб версия гораздо удобнее...