DRAKON.SU https://forum.drakon.su/ |
|
Future Drakon editors' new features https://forum.drakon.su/viewtopic.php?f=62&t=6908 |
Страница 1 из 1 |
Автор: | Luke Alan [ Четверг, 22 Октябрь, 2020 13:46 ] |
Заголовок сообщения: | Future Drakon editors' new features |
These are the features I would like in future Drakon editors, I think they would increase the power of Drakon.
|
Автор: | Владимир Паронджанов [ Четверг, 22 Октябрь, 2020 15:26 ] |
Заголовок сообщения: | Re: New features |
Luke Alan, thank you for your important notes and proposals. Автоматический перевод на русский язык. Цитата: Это те функции, которые я хотел бы видеть в будущих редакторах Drakon, я думаю, они увеличат мощь Drakon.
|
Автор: | Luke Alan [ Четверг, 22 Октябрь, 2020 19:55 ] |
Заголовок сообщения: | Re: New features |
Thank you for translating. I have been using google chrome right click "Translate to..." to read this forum so far. Here is an image mock up using draw.io to illustrate one style of encoding additional helpful information into diagrams, on second thought all it would need are image prefixes for certain things, like here there is a gear icon to indicate something is a diagram or function name, and a blue circle to indicate the parameter named n should be a number. The images used are not neccesarily that important, as long as they are consistent, they will be quickly learned by users. In programming text editors, there is often an autocomplete feature which previews the name of the parameters of a function as you type. One exciting advantage to this feature and diagrams is that such an autocomplete in Drakon could preview not only the name of parameters, but the type icons, as you are writing a function call in a diagram. ![]() To say it another way, Drakon revolutionized coding because it exposes the control flow of programs in a visual way which increases clarity. By giving variable types visual cues, the same process is repeated to give added clarity to programming workflows. Another area to explore this would be tabular data such as large objects stored in variables, akin to database records or spreadsheet data. A visual table in a diagram might be a better option than whatever the programming language syntax is. Each cell in a table could be displayed in a friendlier visual way than ASCII syntax like {} from Lua or "key:value" from JSON. Here's another example to illustrate creating a wizard unit for a specific team number in a game. A new icon is introduced "pink diamond" to signify a string type variable, and a table is used to create the unit variable (associative array) rather than code syntax. See the drawing in the next post. |
Автор: | Владимир Паронджанов [ Четверг, 22 Октябрь, 2020 20:50 ] |
Заголовок сообщения: | Re: New features |
![]() |
Автор: | Владимир Паронджанов [ Четверг, 22 Октябрь, 2020 21:00 ] |
Заголовок сообщения: | Re: New features |
Автоматический перевод на русский Luke Alan писал(а): Спасибо за перевод. Я использовал Google Chrome, щелкнув правой кнопкой мыши «Перевести на ...», чтобы прочитать этот форум.
Вот макет изображения с использованием draw.io, чтобы проиллюстрировать один стиль кодирования дополнительной полезной информации в диаграммы. Если подумать, все, что ему понадобится, это префиксы изображений для определенных вещей, например, здесь есть значок шестеренки, чтобы указать, что что-то представляет собой диаграмму или имя функции и синий кружок, указывающий, что параметр с именем n должен быть числом. Используемые изображения не обязательно так важны, если они согласованы, они будут быстро изучены пользователями. В программных текстовых редакторах часто есть функция автозаполнения, которая предварительно просматривает имя параметров функции по мере ввода. Одним из захватывающих преимуществ этой функции и диаграмм является то, что такое автозаполнение в Drakon может предварительно просматривать не только названия параметров, но и значки типов, когда вы пишете вызов функции на диаграмме. Изображение Другими словами, Drakon произвел революцию в кодировании, потому что он предоставляет поток управления программами визуально, что увеличивает ясность. Предоставляя визуальные подсказки для типов переменных, тот же процесс повторяется, чтобы добавить ясности в рабочие процессы программирования. Еще одна область для изучения - табличные данные, такие как большие объекты, хранящиеся в переменных, подобных записям базы данных или данным электронных таблиц. Визуальная таблица на диаграмме может быть лучшим вариантом, чем любой синтаксис языка программирования. Каждая ячейка в таблице может отображаться более удобным визуальным способом, чем синтаксис ASCII, например {} из Lua или «ключ: значение» из JSON. Вот еще один пример, иллюстрирующий создание юнита волшебника для определенного номера команды в игре. Появился новый значок «розовый ромб» для обозначения переменной строкового типа, а для создания переменной единицы (ассоциативный массив) используется таблица, а не синтаксис кода. |
Автор: | Luke Alan [ Четверг, 22 Октябрь, 2020 22:43 ] |
Заголовок сообщения: | Re: Future Drakon editors' new features |
A final extension to codifying visual cues and removing language-specific syntax would be for expressions involving mathematical and logical operators such as: Equal to Greater than Lesser than Addition Multiplication Division Subtraction etc (and their combinations) Each one of these symbols could be replaced with a 'special form' which consists of one or more images, and placeholders for variables or primitives such as numbers/strings. For example, every one of these operators requires a left side and a right side to the operator. Therefore, every special form would consist of a left side partial expression, and a right side partial expression. The operator between the two could be replaced by a unique image. Hovering the image with the mouse, could display in text what that operator means. For example, hovering a greater than or equal to icon would simply state in a text tooltip "greater than or equal to". Trying to use one of these special forms without a left or right side partial expression should throw an in-editor error and highlight the special form icon as a problem. There should also be a right click option for the special form icon, such as "greater than or equal to" that allows you to transform it to any other special form, such as "equal to". Pros: This could remove virtually all of a programming language's specific syntax. If variables, including arrays/associative arrays, primitives, control flow, and expressions are all in a diagrammatic and 'image-based' form, there can be a unified visual syntax which is intuitive for everyone to comprehend. Images that signify meaning also transcend human language barriers such as English or Russian, the icon can be the same no matter the human user's language of choice. Here is what the image for 'greater than or equal to' might look like. As you can tell, it would look very similar to the ASCII version. The purpose of making it an image is to remove as much syntax from what the user can type. Ideally, the user never has to type syntax such as quotes to encapsulate strings, or commas for lists, or brackets for arrays, or special characters for arithmetic or logical operators. ![]() The only thing at this point that isn't made into a nice form then would be variable (and function) names, such as diagram names themselves, which have to be created with ugly snake_case or camelCase style names. In lisp, they have a somewhat nicer hyphen-style naming, but it's still not natural. One solution to this is to have an editor preference which, when turned on, automatically hides underscores in variable and diagram names and replaces it with white space. This would be for viewing only, the source would remain unchanged. It would simply be a sugar layer for the human reader. In addition, whitespace used when creating variables and diagram names would automatically be replaced with underscores or made into a single string of camel case, or whatever style option the Drakon editor IDE had and the user selected from. The point is, that using a visual view layer with Drakon that is separate from the code, we should not in theory have to use conventional programming crutches and can make the readability for humans higher. |
Автор: | Владимир Паронджанов [ Пятница, 23 Октябрь, 2020 07:55 ] |
Заголовок сообщения: | Re: Future Drakon editors' new features |
Автоперевод на русский Luke Alan писал(а): Окончательное расширение кодифицируя визуальных подсказок и удаление синтаксиса конкретного языка будет для выражений , включающих математических и логических операторов , таких как: , равным больше , чем меньше , чем Сложение Умножение Division Вычитание и т.д. (и их комбинации) Каждый из этих символов может быть заменен «специальная форма», которая состоит из одного или нескольких изображений и заполнителей для переменных или примитивов, таких как числа / строки. Например, для каждого из этих операторов требуются левая и правая части оператора. Следовательно, каждая специальная форма будет состоять из частичного выражения с левой стороны и частичного выражения с правой стороны. Оператор между ними может быть заменен уникальным изображением. При наведении курсора мыши на изображение можно отобразить в тексте то, что означает этот оператор. Например, при наведении курсора на значок «больше или равно» в текстовой подсказке будет просто указано, что «больше или равно». Попытка использовать одну из этих специальных форм без частичного выражения левой или правой стороны должна вызвать ошибку в редакторе и выделить значок специальной формы как проблему. Также должен быть вариант правой кнопки мыши для значка специальной формы, такой как «больше или равно», который позволяет преобразовать его в любую другую специальную форму, Плюсы: это может удалить практически весь специфический синтаксис языка программирования. Если все переменные, включая массивы / ассоциативные массивы, примитивы, поток управления и выражения, представлены в схематической и «графической» форме, может существовать единый визуальный синтаксис, который будет интуитивно понятен каждому. Образы, которые означают смысл, также выходят за пределы человеческого языкового барьера, такого как английский или русский, значок может быть одинаковым, независимо от языка, выбранного пользователем. Вот как может выглядеть изображение для слова «больше или равно». Как видите, он будет очень похож на версию в формате ASCII. Цель создания изображения - удалить как можно больше синтаксиса из того, что пользователь может вводить. В идеале пользователю никогда не нужно вводить синтаксис, такой как кавычки для инкапсуляции строк, запятые для списков, скобки для массивов или специальные символы для арифметических или логических операторов. Изображение Единственное, что на данный момент не имеет хорошей формы, это имена переменных (и функций), такие как сами имена диаграмм, которые должны быть созданы с уродливыми именами в стиле snake_case или camelCase. В lisp они имеют несколько более приятное именование в стиле дефиса, но это все еще неестественно. Одним из решений этого является наличие предпочтения редактора, которое при включении автоматически скрывает подчеркивание в именах переменных и диаграмм и заменяет их пробелами. Это будет только для просмотра, источник останется без изменений. Это было бы просто сахарным слоем для человеческого читателя. Кроме того, пробелы, используемые при создании переменных и имен диаграмм, будут автоматически заменены подчеркиванием или преобразованы в одну строку с верблюжьим регистром или любой другой вариант стиля, который был в IDE редактора Drakon и из которого выбрал пользователь. Из Википедии Цитата: CamelCase (с англ. — «ВерблюжийРегистр», также «ГорбатыйРегистр», «СтильВерблюда») — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово внутри фразы пишется с прописной буквы.
Стиль получил название CamelCase, поскольку прописные буквы внутри слова напоминают горбы верблюда (англ. Camel). |
Автор: | Владимир Паронджанов [ Суббота, 24 Октябрь, 2020 08:38 ] |
Заголовок сообщения: | Re: Future Drakon editors' new features |
Dear Luke Alan, if You want You can develop the new DRAKON-editor with new features by modification of the Drakon.Tech. The source code of the Drakon.Tech and DRAKON Editor is open (public domain). You can do it yourself or together with Stepan Mitkin. Is it interesting for You? ================================== Luke Alan, при желании Вы можете разработать новый ДРАКОН-редактор с новыми функциями путем модификации Drakon.Tech. Исходный код редактора Drakon.Tech и DRAKON Editor является открытым (общественное достояние). Вы можете сделать это сами или вместе со Степаном Митькиным. Вам это интересно? |
Автор: | Luke Alan [ Суббота, 24 Октябрь, 2020 09:45 ] |
Заголовок сообщения: | Re: Future Drakon editors' new features |
Владимир Паронджанов писал(а): Luke Alan, if You want You can develop the new DRAKON-editor with new features by modification of DrakonTech. Source code of DrakonTech and DRAKON Editor is open (public domain). You can do it yourself or together with Stepan Mitkin. Is it interesting for You? I have already been thinking about something like this, however I would rather create a single new diagram specification which builds to any target programming language. This would be accomplished by removing language-specific syntax from the diagram view. The main languages I'm personally interested in targeting are Lua and Javascript, and they are somewhat similar, I feel confident they could share the same unified diagram in the future. For example: in Javascript equality is done with triple equals and in Lua it's done with double equals. Having to learn these syntax rules for each language really slows down a novice. In a diagram, the syntax could be unified with an 'equality image', which builds to either of those forms based on the target language chosen. This way, you don't have to rewrite the diagram to go from Javacript to Lua or vice versa. Steps that would have to be taken:
My main issue is that I'm an novice programmer. I'm not good at comprehending code others have written. It would take me weeks of dedicated time to even get a grasp on the drakon.tech source and get an idea where to begin, and I have a full time job at the moment in unrelated engineering work. If I had the time though the first thing I would do is direct all of my efforts at a new Drakon editor, as I believe it's the next big leap in human programming but it requires substantial research and development for the IDE tooling to make it seamless enough that people switch from the text editor workflow they are used to. One area that this kind of thinking is already trending in is game development. Two of the main game development engines, Unity and Unreal Engine, already have a diagram-based way to implement game logic. Sadly, they did not incorporate the wise principles of Drakon diagrams into their solutions, and so the diagrams are spaghetti-like messes which quickly become confusing and look like this: See the image in the next post. However, it's a step towards the right direction which ultimately I believe will be a combination of that style with the principles of Drakon in terms of structure and organization. |
Автор: | Владимир Паронджанов [ Суббота, 24 Октябрь, 2020 10:28 ] |
Заголовок сообщения: | Re: Future Drakon editors' new features |
Luke Alan писал(а): Я уже думал о чем-то подобном, но я бы предпочел создать единую новую спецификацию диаграммы, которая подходит для любого целевого языка программирования. Это можно сделать, удалив синтаксис, зависящий от языка, из представления диаграммы.
Основными языками, которые лично меня интересуют для таргетинга, являются Lua и Javascript, и они в чем-то похожи, я уверен, что в будущем они могут использовать одну и ту же унифицированную диаграмму. Например: в Javascript равенство выполняется с тройным равенством, а в Lua - с двойным равенством. Необходимость изучать эти синтаксические правила для каждого языка действительно замедляет новичка. На диаграмме синтаксис может быть объединен с «изображением равенства», которое строится для любой из этих форм на основе выбранного целевого языка. Таким образом, вам не нужно переписывать диаграмму, чтобы перейти с Javacript на Lua или наоборот. Шаги, которые необходимо предпринять:
Моя главная проблема в том, что я начинающий программист. Я плохо разбираюсь в коде, написанном другими. Мне потребовались бы недели посвященного времени, чтобы хотя бы разобраться в исходнике drakon.tech и понять, с чего начать, а в настоящее время у меня есть постоянная работа в несвязанной инженерной работе. Если бы у меня было время, первое, что я сделал бы, - это направил все свои усилия на новый редактор Drakon, поскольку я считаю, что это следующий большой скачок в человеческом программировании, но он требует значительных исследований и разработок для инструментария IDE, чтобы сделать его бесшовным. достаточно, чтобы люди переключались с рабочего процесса текстового редактора, к которому они привыкли. Одна из областей, в которой такое мышление уже имеет тенденцию, - это разработка игр. Два основных движка разработки игр, Unity и Unreal Engine, уже имеют основанный на диаграммах способ реализации игровой логики. К сожалению, они не включили мудрые принципы диаграмм Дракона в свои решения, и поэтому диаграммы представляют собой беспорядок, похожий на спагетти, который быстро сбивает с толку и выглядит следующим образом: Однако это шаг в правильном направлении, который, в конечном счете, я считаю сочетание этого стиля с принципами Дракона с точки зрения структуры и организации. |
Автор: | Luke Alan [ Суббота, 08 Январь, 2022 09:47 ] |
Заголовок сообщения: | Re: Future Drakon editors' new features |
It has been two years since I made this thread, and I still use Drakon Editor (DrakonLua and DrakonJS) every single day. I might be mistaken, if there are still people using Drakon Editor for their work, but if not I probably use Drakon Editor more than anyone else these days. First of all, the special syntax of DrakonLua and DrakonJS is a great help and is a step in the right direction, although I believe it should be accomplished with graphics rather than just new lines and indents. I've added more to my wishlist in these 2 years. I'm still unable to develop a "DRAKON-2 IDE" myself, but maybe one day. I believe in the concept more than ever. "Cached Diagram Building / Build Speed Boost" - One major drawback I've found recently is that in large .drn files, compilation time can take around 30 seconds. This is with about 20,000 lines of code, some codebases are much larger. One workaround is to break up the files into multiple .drns, but then you lose the ability to use Go to diagram in a single file, and it just becomes a choice between lesser evils. To ideally solve this problem, each individual diagram should store a variable if it has been modified since it was last compiled - if not, it should use the last compiled code instead of compiling again. I believe this will drastically speed up compile times, as often users are just changing one icon in one diagram, and having to wait for thousands of other diagrams to recompile for no reason. "Diagram-specific Undo History" - Another feature which would be really beneficial is diagram-specific undo history AND a global undo history, with their own shortcuts. This way, you could open up a diagram and undo the latest changes just to that diagram, without having to traverse the global undo history. "Comment/Uncomment Diagram" - Something else I wish I had was the ability to completely comment out the entire body of a diagram, all of the icons, with a single click or hotkey, and uncomment them all with a single click or hotkey. "Unified Select/If Icon" - It has been in the back of my mind that we don't actually need a select icon and an if icon, we just need a more advanced select icon, and hopefully a more compact one. Case icons underneath a select icon take up way too much vertical and horizontal space in my opinion, they should be right up against one another. Only two case icons should be created for a select icon by default (acting as a If icon), prepopulated with a Yes and No keyword, which can be inverted with a right click menu option just like an If icon. This will force users to create separate action icons to capture the booleans they wish to select against. I'm usually doing that anyway as a best practice before my if icons. I've tried to show an alternative and more compact style for the Select and Case icons here. I'm advocating for removing the if icon shown here altogether, it's just shown for comparison, the Select and Case icons would accomplish the same thing. ![]() "Dashed Arrow Loop" - I suggest having a simpler 'dashed arrow' which executes icons from the bottom to the top. Dashed arrows would always come out of green loop bottom icons, but could also be used on vertical lines (such as in a Case icon skewer). Dashed arrow loops always go to the Left and Up, to not interfere with right-flowing Select / Case layouts. ![]() There are literally hundreds more features I have in mind, but they require so much alteration that it's not worth it to discuss them yet, these core features would likely have to be implemented first anyway before more advanced features could be built on top of the foundation. |
Автор: | Владимир Паронджанов [ Воскресенье, 09 Январь, 2022 08:34 ] |
Заголовок сообщения: | Re: Future Drakon editors' new features |
Luke Alan писал(а): Прошло два года с тех пор, как я создал эту тему, и я до сих пор использую Drakon Editor (DrakonLua и DrakonJS) каждый божий день.
Я могу ошибаться, если есть люди, использующие Drakon Editor для своей работы, но если нет, то я, вероятно, использую Drakon Editor больше, чем кто-либо другой в наши дни. Прежде всего, особый синтаксис DrakonLua и DrakonJS очень помогает и является шагом в правильном направлении, хотя я считаю, что это должно быть выполнено с помощью графики, а не просто новых строк и отступов. Я добавил больше в свой список пожеланий за эти 2 года. Сам пока не могу разработать "DRAKON-2 IDE", но может когда-нибудь. Я верю в эту концепцию больше, чем когда-либо. "Cached Diagram Building / Build Speed Boost" «Построение кэшированных диаграмм / ускорение сборки». Один из основных недостатков, который я недавно обнаружил, заключается в том, что в больших файлах .drn время компиляции может занять около 30 секунд. Это около 20 000 строк кода, некоторые кодовые базы намного больше. Одним из обходных путей является разбиение файлов на несколько .drns, но тогда вы теряете возможность использовать «Перейти к диаграмме» в одном файле, и это просто становится выбором между меньшим злом. Чтобы идеально решить эту проблему, каждая отдельная диаграмма должна хранить переменную, если она была изменена с момента последней компиляции, а если нет, она должна использовать последний скомпилированный код вместо повторной компиляции. Я считаю, что это значительно ускорит время компиляции, так как часто пользователи просто меняют один значок на одной диаграмме и вынуждены ждать, пока тысячи других диаграмм будут перекомпилированы без всякой причины. "Diagram-specific Undo History" «История отмены для конкретной диаграммы» Еще одна функция, которая была бы действительно полезной, — это история отмены для конкретной диаграммы И глобальная история отмены со своими собственными ярлыками. Таким образом, вы можете открыть диаграмму и отменить последние изменения только в этой диаграмме, не просматривая глобальную историю отмен. «Комментировать/раскомментировать диаграмму». Еще мне хотелось бы иметь возможность полностью закомментировать все тело диаграммы, все значки одним щелчком мыши или горячей клавишей и раскомментировать их все одним щелчком мыши или горячей клавишей. "Unified Select/If Icon" «Унифицированная икона Выбор/если» Я всегда думал, что нам на самом деле не нужны значок выбора и значок «если», нам просто нужен более продвинутый значок выбора и, надеюсь, более компактный. На мой взгляд, иконы Вариант под иконой Выбор занимают слишком много места по вертикали и горизонтали, они должны быть прямо напротив друг друга. По умолчанию для значка выбора должны быть созданы только два значка случая (действующие как значок «Если»), предварительно заполненные ключевыми словами «Да» и «Нет», которые можно инвертировать с помощью пункта меню правой кнопки мыши, как значок «Если». Это заставит пользователей создавать отдельные значки действий для захвата логических значений, против которых они хотят выбирать. В любом случае, я обычно делаю это в качестве лучшей практики перед моими значками if. Здесь я попытался показать альтернативный и более компактный стиль для значков Select и Case. Изображение "Dashed Arrow Loop" «Цикл Стрелка с пунктиром» я предлагаю использовать более простую «пунктирную Стрелку», которая выполняет иконы снизу вверх. Пунктирные Стрелки всегда будут выходить из нижних икон зеленого цикла, но их также можно использовать на вертикальных линиях (например, в шампуре иконы Выбор). Петли пунктирных Стрелок всегда идут влево и вверх, чтобы не мешать расположенным вправо переключателям Select/Case. Изображение Есть буквально сотни других функций, которые я имею в виду, но они требуют так много изменений, что пока не стоит их обсуждать, эти основные функции, вероятно, должны быть реализованы в первую очередь в любом случае, прежде чем более продвинутые функции могут быть построены поверх фундамента. . |
Автор: | Владимир Паронджанов [ Воскресенье, 09 Январь, 2022 23:59 ] |
Заголовок сообщения: | Re: Future Drakon editors' new features |
Luke Alan project: See the whole list of topics and posts |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |