DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 11:24

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 13 ] 
Автор Сообщение
 Заголовок сообщения: Future Drakon editors' new features
СообщениеДобавлено: Четверг, 22 Октябрь, 2020 13:46 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
These are the features I would like in future Drakon editors, I think they would increase the power of Drakon.

  • All of the features already present in the latest drakon editor (desktop)

  • All of the features present in drakon tech such as auto arrangement of diagrams and adding/pasting by clicking + icons.

  • Dark theme which is easy on the eyes over many hours

  • Keyboard navigation for all functionality, such as arrow key navigation to select where to add a new icon and to traverse the diagram, as well as all other functionality with keyboard shortcuts

  • Single line icons. It would be nice if the only option was single line icons. I have ideas for how to improve the only case where multi line is beneficial: lists of things like parameters or arrays/associative arrays. See "mini-icons".

  • Mini icons for lists, such as parameters or arrays/associative arrays would be able to be added inside other icons, and would have their own outline shape and border color to distinguish between the three options (parameters, arrays, associative arrays). These mini icons would be on 'new lines' inside the parent icon, removing the need for making new lines manually or using commas.

  • Mini type icons having its own unique outline shape and border color for each type could be added inside parent icons such as action or question icons. These type icons would be: string, boolean, number, function, array, associative array, etc. These mini icons would remove plain text inside icons and instead encode all of the data in types visually - these type mini icons could be added by hotkeys or right click context menus.

  • Trigger icons would be unique icon headers for diagrams to indicate this diagram is an 'entry' point, such as when an event fires, or a user provides some input like a mouse click or keypress that triggers the diagram to fire. This would help distinguish which diagrams are the 'initiators' of a program procedure, and helps remove the need for silheouttes, which can get too big to fit on a screen.

  • Parent/Child diagrams and scope. This feature would help abstraction by allowing diagrams to exist only in the scope of being a child to another parent diagram, therefore, you could have duplicate diagrams in the same file as long as they were children to different parents. Imagine you have two parent diagrams, one is called 'arithmetic' and the other is called 'string'. Under each of these parent diagrams there is a child diagram named 'add'. One is for adding arithmetic, the other is for adding strings together. Because they are child diagrams, they can share the same name and would exist in a hierarchical relationship in the diagram tree, below their parent diagrams. This also helps show which diagrams are only related to certain other diagrams, and helps organize a large code base.

  • Custom type icons should be able to be created by users, by using custom RGB color borders and a selection of custom outline shapes. The reason custom types may be useful is for specific domains where certain objects are commonly used: such as vectors, seconds, milliseconds, cartesian points, feet, meters, game characters, user accounts, etc. By making them into their own mini icon types it helps to identify them at a glance and abstract them into single entities, rather than passing around named arrays or associative arrays which all look too similar.

  • Find and replace should allow for three modes: targeting entire diagrams, the names of diagrams only, or the bodies of diagrams only. This helps with refactoring the names of diagrams without messing up the body of each diagram accidentally.

  • Global and local variable mini-icons should be allowed instead of forcing only local variables to be inherently created. In the context of games especially, global objects are often very common, and it would be useful to know if variables are global or not in the editor without having to keep this information in human memory.

  • Diagram metadata should be visible on the diagram tree, such as numbers next to each diagram name indicating things like: how many icons are in the diagram, how many parameters are specified in the diagram, how many branches does the diagram have. This helps show which diagrams need refactoring because they are too complex, without having to traverse each diagram and count yourself.

  • Readable .drn source files. It would be useful if source .drn files were readable ASCII diagrams, because then they could be parsed by text editors to perform regex operations and so on, if the drakon editor itself hasn't implemented all of those text manipulation features. It would also help unify the .drn source format to be easier to convert one type of language to another, because the diagram would stay the same only the syntax behind the scenes would change.

  • Breadcrumbs at the top of the editor to show where you are in relation to the Parent/Child diagram hierarchy would be useful. Imagine you are looking at the `add` diagram from earlier, but you don't know if you're in the `string` child or the `arithmetic` child. Breadcrumbs at the top, like breadcrumbs on webpages, would show you this information. This also aids in abstraction.

  • Autocomplete for variable names and function names based on the existing drn file would be useful.

  • Highlighting functions which are not defined yet in the drn, and variables which are not used yet in the diagram would be useful for refactoring and debugging before code is live.

  • Auto center diagrams which fit totally in the window screen space should be done automatically - not pushing the diagrams to the top right, but instead centering the entire diagram in the center of the drawing space. This should only happen if the diagram would fit in the space at once, otherwise use the existing behavior.

  • The zoom level in the current diagram should be displayed as an overlay, so it's apparent if the zoom is 100% or not at all times.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: New features
СообщениеДобавлено: Четверг, 22 Октябрь, 2020 15:26 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Luke Alan, thank you for your important notes and proposals.

Автоматический перевод на русский язык.
Цитата:
Это те функции, которые я хотел бы видеть в будущих редакторах Drakon, я думаю, они увеличат мощь Drakon.

  • Все функции, уже присутствующие в последней версии редактора Drakon (для ПК)

  • Все функции, присутствующие в d
    Drakon.Tech, такие как автоматическое расположение диаграмм и добавление / вставка нажатием значков +.

  • Темная тема, приятная для глаз в течение многих часов.

  • Клавиатурная навигация для всех функций, таких как навигация по клавишам со стрелками для выбора места добавления нового значка и перемещения по диаграмме, а также для всех других функций с помощью сочетаний клавиш

  • Однострочные значки. Было бы неплохо, если бы единственным вариантом были однострочные значки. У меня есть идеи, как улучшить единственный случай, когда многострочный полезен: списки таких вещей, как параметры или массивы / ассоциативные массивы. Смотрите «мини-иконки».

  • Мини-значки для списков, такие как параметры или массивы / ассоциативные массивы, можно будет добавлять внутри других значков, и они будут иметь собственную форму контура и цвет границы, чтобы различать три варианта (параметры, массивы, ассоциативные массивы) . Эти мини-значки будут на «новых строках» внутри родительского значка, что избавит от необходимости создавать новые строки вручную или с использованием запятых.

  • Значки мини-типа, имеющие собственную уникальную форму контура и цвет границы для каждого типа, могут быть добавлены внутри родительских значков, таких как значки действий или вопросов.

    Эти значки типов могут быть: строка, логическое значение, число, функция, массив, ассоциативный массив и т. Д.

    Эти мини-значки удаляют простой текст внутри значков и вместо этого визуально кодируют все данные в типах - эти мини-значки типов могут быть добавлены с помощью горячих клавиш или щелкните контекстное меню правой кнопкой мыши.

  • Значки триггеров представляют собой уникальные заголовки значков для диаграмм, чтобы указать, что эта диаграмма является точкой входа, например, когда срабатывает событие, или когда пользователь предоставляет какие-либо данные, такие как щелчок мыши или нажатие клавиши, запускающее диаграмму.

    Это помогло бы различать, какие диаграммы являются «инициаторами» программной процедуры, и избавило бы от необходимости использовать силуэты, которые могут стать слишком большими, чтобы поместиться на экране.

  • Родительские / дочерние диаграммы и область видимости. Эта функция поможет абстракции, позволяя диаграммам существовать только в рамках того, что они являются дочерними по отношению к другой родительской диаграмме, поэтому вы можете иметь дубликаты диаграмм в одном файле, если они являются дочерними по отношению к разным родителям. Представьте, что у вас есть две родительские диаграммы, одна называется «арифметической», а другая - «строковой».

    Под каждой из этих родительских диаграмм есть дочерняя диаграмма с именем «добавить». Один предназначен для сложения арифметических операций, другой - для сложения строк. Поскольку они являются дочерними диаграммами, они могут иметь одно и то же имя и существовать в иерархической взаимосвязи в дереве диаграммы под своими родительскими диаграммами. Это также помогает показать, какие диаграммы связаны только с некоторыми другими диаграммами, и помогает организовать большую базу кода.

  • Значки настраиваемого типа должны быть созданы пользователями с использованием настраиваемых цветовых границ RGB и набора настраиваемых форм контура.

    Причина, по которой пользовательские типы могут быть полезны, заключается в определенных доменах, где обычно используются определенные объекты: такие как векторы, секунды, миллисекунды, декартовы точки, футы, метры, игровые персонажи, учетные записи пользователей и т. Д.

    Путем превращения их в свои собственные мини-типы значков это помогает идентифицировать их с первого взгляда и абстрагировать их в отдельные объекты, а не передавать именованные массивы или ассоциативные массивы, которые все выглядят слишком похожими.

  • Функция поиска и замены должна допускать три режима: нацеливание на диаграммы целиком, только на имена диаграмм или только на тела диаграмм. Это помогает рефакторингу имен диаграмм, не повреждая случайно тело каждой диаграммы.

  • Должны быть разрешены мини-иконки глобальных и локальных переменных вместо принудительного создания только локальных переменных. В частности, в контексте игр глобальные объекты часто очень распространены, и было бы полезно знать, являются ли переменные глобальными или нет в редакторе, без необходимости хранить эту информацию в памяти человека.

  • Метаданные диаграммы должны быть видны в дереве диаграммы, например числа рядом с каждым названием диаграммы, указывающие на такие вещи, как: сколько значков на диаграмме, сколько параметров указано в диаграмме, сколько ветвей у диаграммы.

    Это помогает показать, какие диаграммы нуждаются в рефакторинге, поскольку они слишком сложны, без необходимости просматривать каждую диаграмму и подсчитывать самостоятельно.

  • Читаемые исходные файлы .drn. Было бы полезно, если бы исходные файлы .drn представляли собой читаемые диаграммы ASCII, потому что тогда они могли бы анализироваться текстовыми редакторами для выполнения операций с регулярными выражениями и т. Д., Если сам редактор drakon не реализовал все эти функции обработки текста.

    Это также поможет унифицировать исходный формат .drn, чтобы упростить преобразование одного типа языка в другой, потому что диаграмма останется прежней, только синтаксис за кулисами изменится.

  • Полезны хлебные крошки в верхней части редактора, показывающие, где вы находитесь по отношению к иерархии родительских / дочерних диаграмм.

    Представьте, что вы смотрите на диаграмму ʻadd` из ранее, но вы не знаете, находитесь ли вы в дочернем элементе `string` или ʻarithmetic`. Хлебные крошки вверху, как панировочные сухари на веб-страницах, покажут вам эту информацию. Это также помогает в абстракции.

  • Было бы полезно использовать автозаполнение для имен переменных и имен функций на основе существующего файла drn.

  • Выделение функций, которые еще не определены в drn, и переменных, которые еще не используются на диаграмме, было бы полезно для рефакторинга и отладки перед запуском кода.

  • Диаграммы с автоматическим центрированием, которые полностью помещаются в пространство экрана окна, должны выполняться автоматически - не смещая диаграммы в верхний правый угол, а вместо этого центрируя всю диаграмму в центре области рисования.

    Это должно произойти только в том случае, если диаграмма сразу поместится в пространстве, в противном случае используйте существующее поведение.

  • Уровень масштабирования на текущей диаграмме должен отображаться в виде наложения, чтобы было видно, составляет масштаб 100% или не всегда.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: New features
СообщениеДобавлено: Четверг, 22 Октябрь, 2020 19:55 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
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.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: New features
СообщениеДобавлено: Четверг, 22 Октябрь, 2020 20:50 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Изображение


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: New features
СообщениеДобавлено: Четверг, 22 Октябрь, 2020 21:00 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Автоматический перевод на русский
Luke Alan писал(а):
Спасибо за перевод. Я использовал Google Chrome, щелкнув правой кнопкой мыши «Перевести на ...», чтобы прочитать этот форум.

Вот макет изображения с использованием draw.io, чтобы проиллюстрировать один стиль кодирования дополнительной полезной информации в диаграммы.

Если подумать, все, что ему понадобится, это префиксы изображений для определенных вещей, например, здесь есть значок шестеренки, чтобы указать, что что-то представляет собой диаграмму или имя функции и синий кружок, указывающий, что параметр с именем n должен быть числом. Используемые изображения не обязательно так важны, если они согласованы, они будут быстро изучены пользователями.

В программных текстовых редакторах часто есть функция автозаполнения, которая предварительно просматривает имя параметров функции по мере ввода.

Одним из захватывающих преимуществ этой функции и диаграмм является то, что такое автозаполнение в Drakon может предварительно просматривать не только названия параметров, но и значки типов, когда вы пишете вызов функции на диаграмме.

Изображение

Другими словами, Drakon произвел революцию в кодировании, потому что он предоставляет поток управления программами визуально, что увеличивает ясность.

Предоставляя визуальные подсказки для типов переменных, тот же процесс повторяется, чтобы добавить ясности в рабочие процессы программирования.

Еще одна область для изучения - табличные данные, такие как большие объекты, хранящиеся в переменных, подобных записям базы данных или данным электронных таблиц.

Визуальная таблица на диаграмме может быть лучшим вариантом, чем любой синтаксис языка программирования. Каждая ячейка в таблице может отображаться более удобным визуальным способом, чем синтаксис ASCII, например {} из Lua или «ключ: значение» из JSON.

Вот еще один пример, иллюстрирующий создание юнита волшебника для определенного номера команды в игре. Появился новый значок «розовый ромб» для обозначения переменной строкового типа, а для создания переменной единицы (ассоциативный массив) используется таблица, а не синтаксис кода.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Future Drakon editors' new features
СообщениеДобавлено: Четверг, 22 Октябрь, 2020 22:43 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
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.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Future Drakon editors' new features
СообщениеДобавлено: Пятница, 23 Октябрь, 2020 07:55 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Автоперевод на русский
Luke Alan писал(а):
Окончательное расширение кодифицируя визуальных подсказок и удаление синтаксиса конкретного языка будет для выражений , включающих математических и логических операторов , таких как:
,
равным
больше , чем
меньше , чем
Сложение
Умножение
Division
Вычитание и
т.д.
(и их комбинации)

Каждый из этих символов может быть заменен «специальная форма», которая состоит из одного или нескольких изображений и заполнителей для переменных или примитивов, таких как числа / строки.

Например, для каждого из этих операторов требуются левая и правая части оператора. Следовательно, каждая специальная форма будет состоять из частичного выражения с левой стороны и частичного выражения с правой стороны.

Оператор между ними может быть заменен уникальным изображением. При наведении курсора мыши на изображение можно отобразить в тексте то, что означает этот оператор. Например, при наведении курсора на значок «больше или равно» в текстовой подсказке будет просто указано, что «больше или равно».

Попытка использовать одну из этих специальных форм без частичного выражения левой или правой стороны должна вызвать ошибку в редакторе и выделить значок специальной формы как проблему.

Также должен быть вариант правой кнопки мыши для значка специальной формы, такой как «больше или равно», который позволяет преобразовать его в любую другую специальную форму,

Плюсы: это может удалить практически весь специфический синтаксис языка программирования. Если все переменные, включая массивы / ассоциативные массивы, примитивы, поток управления и выражения, представлены в схематической и «графической» форме, может существовать единый визуальный синтаксис, который будет интуитивно понятен каждому.

Образы, которые означают смысл, также выходят за пределы человеческого языкового барьера, такого как английский или русский, значок может быть одинаковым, независимо от языка, выбранного пользователем.

Вот как может выглядеть изображение для слова «больше или равно». Как видите, он будет очень похож на версию в формате ASCII. Цель создания изображения - удалить как можно больше синтаксиса из того, что пользователь может вводить.

В идеале пользователю никогда не нужно вводить синтаксис, такой как кавычки для инкапсуляции строк, запятые для списков, скобки для массивов или специальные символы для арифметических или логических операторов.

Изображение

Единственное, что на данный момент не имеет хорошей формы, это имена переменных (и функций), такие как сами имена диаграмм, которые должны быть созданы с уродливыми именами в стиле snake_case или camelCase.

В lisp они имеют несколько более приятное именование в стиле дефиса, но это все еще неестественно. Одним из решений этого является наличие предпочтения редактора, которое при включении автоматически скрывает подчеркивание в именах переменных и диаграмм и заменяет их пробелами.

Это будет только для просмотра, источник останется без изменений. Это было бы просто сахарным слоем для человеческого читателя.

Кроме того, пробелы, используемые при создании переменных и имен диаграмм, будут автоматически заменены подчеркиванием или преобразованы в одну строку с верблюжьим регистром или любой другой вариант стиля, который был в IDE редактора Drakon и из которого выбрал пользователь.


Из Википедии
Цитата:
CamelCase (с англ. — «ВерблюжийРегистр», также «ГорбатыйРегистр», «СтильВерблюда») — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово внутри фразы пишется с прописной буквы.

Стиль получил название CamelCase, поскольку прописные буквы внутри слова напоминают горбы верблюда (англ. Camel).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Future Drakon editors' new features
СообщениеДобавлено: Суббота, 24 Октябрь, 2020 08:38 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
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 является открытым (общественное достояние).

Вы можете сделать это сами или вместе со Степаном Митькиным.
Вам это интересно?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Future Drakon editors' new features
СообщениеДобавлено: Суббота, 24 Октябрь, 2020 09:45 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
Владимир Паронджанов писал(а):
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:
  • Make a new source format, such as in JSON, to describe diagrams in code form, this becomes the new .drn equivalent.
  • Create a parser to turn the JSON source into HTML/CSS diagrams on an interactive web app (parser.drn), this separates the concerns between displaying the diagram and the source specification. It would function similar to Markdown.
  • Create a transpiler to turn the JSON source into Javascript, Lua, etc. (lua_transpiler.drn, js_transpiler.drn, etc.)
  • Create an interactive web app that lets you modify the JSON in an intuitive way by interacting with the HTML/CSS diagram view (app.drn) using the mouse and keyboard. It would primarily require features to let you create/read/update/destroy icons and diagrams in the JSON source, by interacting with the HTML/CSS model view.
  • Add features to the web app like a toolbar, keyboard shortcuts, canvas zoom and panning, etc. I'm not sure what drakon.tech used but electron.js looks promising, Visual Studio Code, Draw.io, and Discord were all created using it and draw.io is open source. The apps look a lot like google docs/sheets, they look similar to desktop apps but can be targeted to run in the browser or the desktop.

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.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Future Drakon editors' new features
СообщениеДобавлено: Суббота, 24 Октябрь, 2020 10:28 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Luke Alan писал(а):
Я уже думал о чем-то подобном, но я бы предпочел создать единую новую спецификацию диаграммы, которая подходит для любого целевого языка программирования. Это можно сделать, удалив синтаксис, зависящий от языка, из представления диаграммы.

Основными языками, которые лично меня интересуют для таргетинга, являются Lua и Javascript, и они в чем-то похожи, я уверен, что в будущем они могут использовать одну и ту же унифицированную диаграмму.

Например: в Javascript равенство выполняется с тройным равенством, а в Lua - с двойным равенством. Необходимость изучать эти синтаксические правила для каждого языка действительно замедляет новичка.

На диаграмме синтаксис может быть объединен с «изображением равенства», которое строится для любой из этих форм на основе выбранного целевого языка.

Таким образом, вам не нужно переписывать диаграмму, чтобы перейти с Javacript на Lua или наоборот.

Шаги, которые необходимо предпринять:
  • Создайте новый исходный формат, такой как JSON, для описания диаграмм в кодовой форме, он станет новым эквивалентом .drn.
  • Создайте синтаксический анализатор для преобразования источника JSON в диаграммы HTML / CSS в интерактивном веб-приложении (parser.drn), это разделит проблемы между отображением диаграммы и спецификацией источника. Он будет работать аналогично Markdown.
  • Создайте транспилятор для преобразования исходного кода JSON в Javascript, Lua и т. Д. (Lua_transpiler.drn, js_transpiler.drn и т. Д.)
  • Создайте интерактивное веб-приложение, которое позволяет изменять JSON интуитивно понятным способом, взаимодействуя с представлением диаграммы HTML / CSS (app.drn) с помощью мыши и клавиатуры. В первую очередь потребуются функции, позволяющие создавать / читать / обновлять / уничтожать значки и диаграммы в источнике JSON, взаимодействуя с представлением модели HTML / CSS.
  • Добавьте в веб-приложение такие функции, как панель инструментов, сочетания клавиш, масштабирование и панорамирование холста и т. Д. Я не уверен, что использовал drakon.tech, но Electron.js выглядит многообещающе, были созданы Visual Studio Code, Draw.io и Discord. используя его, и draw.io имеет открытый исходный код.
    Приложения очень похожи на документы / листы Google, они похожи на настольные приложения, но их можно настроить для запуска в браузере или на рабочем столе.

Моя главная проблема в том, что я начинающий программист. Я плохо разбираюсь в коде, написанном другими. Мне потребовались бы недели посвященного времени, чтобы хотя бы разобраться в исходнике drakon.tech и понять, с чего начать, а в настоящее время у меня есть постоянная работа в несвязанной инженерной работе.

Если бы у меня было время, первое, что я сделал бы, - это направил все свои усилия на новый редактор Drakon, поскольку я считаю, что это следующий большой скачок в человеческом программировании, но он требует значительных исследований и разработок для инструментария IDE, чтобы сделать его бесшовным. достаточно, чтобы люди переключались с рабочего процесса текстового редактора, к которому они привыкли.

Одна из областей, в которой такое мышление уже имеет тенденцию, - это разработка игр. Два основных движка разработки игр, Unity и Unreal Engine, уже имеют основанный на диаграммах способ реализации игровой логики.

К сожалению, они не включили мудрые принципы диаграмм Дракона в свои решения, и поэтому диаграммы представляют собой беспорядок, похожий на спагетти, который быстро сбивает с толку и выглядит следующим образом:

Однако это шаг в правильном направлении, который, в конечном счете, я считаю сочетание этого стиля с принципами Дракона с точки зрения структуры и организации.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Future Drakon editors' new features
СообщениеДобавлено: Суббота, 08 Январь, 2022 09:47 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
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.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Future Drakon editors' new features
СообщениеДобавлено: Воскресенье, 09 Январь, 2022 08:34 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
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.

Изображение

Есть буквально сотни других функций, которые я имею в виду, но они требуют так много изменений, что пока не стоит их обсуждать, эти основные функции, вероятно, должны быть реализованы в первую очередь в любом случае, прежде чем более продвинутые функции могут быть построены поверх фундамента. .


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Future Drakon editors' new features
СообщениеДобавлено: Воскресенье, 09 Январь, 2022 23:59 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Luke Alan project: See the whole list of topics and posts


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 13 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB