DRAKON.SU

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

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




Начать новую тему Ответить на тему  [ Сообщений: 19 ] 
Автор Сообщение
 Заголовок сообщения: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 07:10 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
This is a new and I suspect highly controversial theory for best practice in writing DRAKON diagram functions.

First of all, silhouettes should never be used, only primitive diagrams with one main skewer.

There should never be more than two parameters on a function parameter icon. If you need many pieces of data, encapsulate a paramater into an object. If you need many objects, encapsulate objects which relate to one another into a parent object. One exception to this rule, where you can use 3 parameters, is for asynchronous functions which sometimes have an arbitrary delay, callback function parameter, or something like that. These parameters don't belong in an object so you can break the rule. The 'no more than two' rule applies only to parameters relative to the logic of the function. In no case is more than 3 parameters allowed.

Example: Most A-star pathfinding search algorithms operate on three parameters: a grid, a start cell [x,y], and an end cell [x,y]. You can encapsulate all three of these into a search object (search.grid, search.start_cell, search.end_cell), because all of this data relates to each other in some way, it doesn't matter how. This greatly simplifies passing these pieces of data to child functions, it is much easier to pass `search` than grid, start_cell, and end_cell separately, and rely on getting the positional parameters ordered correctly.

There should never be more than two branches created by If icons in a single diagram. This does not mean you cannot use multiple If icons in one diagram, they just have to all share the same vertical lines. If icons should always be on the happy path, otherwise known as the main vertical line.

There should never be more than one switch statement in a diagram, and it should always be on the 'happy path', otherwise known as the main vertical line.

There should never be more than one loop in a diagram, and it should always be on the 'happy path', otherwise known as the main vertical line.

Never use early return explicitly, there should never be more than one 'return' statement per vertical branch, it should always be right before the end icon, and there should only be one 'return' per vertical line, one for the main skewer line and one for the secondary one if you're using "if icons" in that diagram. You can still have 'early return', just without an explicit return block high up in your diagram. Instead, use an if icon to implement early return as shown below:

Изображение

Diagrams (functions) should do one thing and one thing only, which keeps their scope and vertical height to a minimum, especially when paired with the above principles.

Loop icons, which include arrow loops and foreach loops, should always have an arrow representing where the loop begins and terminates, and the arrow should move left and upwards, then back to the right. This is opposite the normal flow of DRAKON diagrams, and is suggested to prevent line intersections with many loops. As long as the preceding principles are followed, it should be impossible to have line intersections even when drawing freehand.

Unfortunately, I don't know how to make the DRAKON editor behave this way regarding loop arrows, or how to add them to foreach icons, so for now I still use the built in way, I'm just noting this best practice here because I think it was a mistake in the original DRAKON implementation to make loops arrow-less or arrow that flow to the right, potentially conflicting with if icon lines.

I have written over 4,000 functions in DRAKON for a complex board game (similar to chess, but with many advanced mechanics). These principles are ones I've derived from making so many diagrams. Unfortunately, most of the diagrams I've written don't follow these rules, and those are the problematic ones. I simply hadn't discerned these rules yet as I was a novice DRAKON user and programmer when I started.

It does take longer to write diagrams this way, because you have to write a lot more diagrams. However, the diagrams are smaller, and in my case always fit on my screen vertically, which really helps keeps diagrams readable, comprehenisble, reusable, and extendable.

Here is a small example of a function "before" refactoring, and its refactored version, along with its full child functions, showing how these best practices in the case of 'if icons' can make comprehending the logic of your program so much easier.

See the next post.


Последний раз редактировалось Luke Alan Пятница, 23 Июль, 2021 09:15, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 08:52 

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

GOOD DIAGRAM(S):
Изображение

It is perfectly fine, if not expected, that you
first compose diagrams the bad way, without following
these rules.

However, if you value maintainability and readability,
you should refactor the diagrams as soon as the feature
you're implementing works.

I suggest keeping two folders in your DRAKON editor
"unrefactored" and "refactored", and move diagrams
between these folders to keep track of which ones
you've made according to the rules.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 09:52 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Dear Luke Alan, your diagrams readability in this forum is not good.
It is desirable to delete inverse coloring. Please, change the black color to the white one in your diagram main color.
And change the white color to the black one in your diagrams lines and the text.
Thank you.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 10:27 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
It is not a simple thing to change the theme
for my DRAKON editor, I installed a custom
theme and it's a bit of a hack together..
even the sides are colored dark to prevent
eye strain.

Изображение

You can use 'Dark Reader' extension for chrome
to apply a dark theme to this forum like I do,
or right click the images and click 'open image
in new window', which will take you to imgur -
which as it happens uses a dark theme.

Изображение


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 10:33 

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

Luke Alan писал(а):
Это новая, и я подозреваю, что это весьма противоречивая теория для лучшей практики написания функций диаграмм DRAKON.

Во-первых, никогда не следует использовать силуэты, только примитивные схемы с одной основной шпажкой.

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

Пример: большинство алгоритмов поиска пути A-star работают с тремя параметрами: сеткой, начальной ячейкой [x, y] и конечной ячейкой [x, y]. Вы можете инкапсулировать все три из них в объект поиска (search.grid, search.start_cell, search.end_cell), потому что все эти данные каким-то образом связаны друг с другом, неважно каким образом. Это значительно упрощает передачу этих фрагментов данных дочерним функциям, гораздо проще передавать `search`, чем grid, start_cell и end_cell по отдельности, и полагаться на правильное упорядочение позиционных параметров.

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

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

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

Никогда не используйте явно ранний возврат, никогда не должно быть более одного оператора return на вертикальную ветвь, он всегда должен быть прямо перед значком конца, и должен быть только один оператор return на вертикальную линию, один для основной линии вертела. и один для второстепенного, если вы используете на этой диаграмме «значки if». У вас все еще может быть «ранний возврат», только без явного блока возврата вверху диаграммы. Вместо этого используйте значок if для реализации раннего возврата, как показано ниже:

Изображение

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

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

К сожалению, я не знаю, как заставить редактор DRAKON вести себя таким образом в отношении стрелок цикла или как добавить их к значкам foreach, поэтому пока я все еще использую встроенный способ, я просто отмечаю здесь эту передовую практику, потому что Я думаю, что в исходной реализации DRAKON было ошибкой сделать петли без стрелок или стрелки, которые текут вправо, что потенциально противоречило бы строкам значков if.

Я написал в ДРАКОН более 4000 функций для сложной настольной игры (похожей на шахматы, но с множеством продвинутых механик). Эти принципы я извлек из множества диаграмм. К сожалению, большинство диаграмм, которые я написал, не следуют этим правилам, и это проблемные. Я просто еще не разобрался с этими правилами, так как был начинающим пользователем и программистом ДРАКОНа, когда начинал.

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

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

Обратите внимание:

Совершенно нормально, если вы не ожидаете, что вы сначала составите диаграммы плохим способом, не следуя
этим правилам.

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

Я предлагаю оставить в редакторе DRAKON две папки «без рефакторинга» и «с рефакторингом» и перемещать диаграммы между этими папками, чтобы отслеживать, какие из них вы создали в соответствии с правилами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 11:28 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Luke Alan писал(а):
It is not a simple thing to change the theme for my DRAKON editor, I installed a custom theme and it's a bit of a hack together.. even the sides are colored dark to prevent eye strain.

Of course, you are quite right, it is very important to use colored dark to prevent eye strain.

But to demonstrate to other people the definite drakon-diagrams may be it would be useful including in your editor some convertor converting drakon-diagrams to good-readably people-friendly view.

Luke Alan писал(а):
You can use 'Dark Reader' extension for chrome
to apply a dark theme to this forum like I do,
or right click the images and click 'open image
in new window', which will take you to imgur -
which as it happens uses a dark theme.
Thank you, it is a good advice but I am afraid that many forum participants and guests are not ready to follow this advice as extra actions needed.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 12:49 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
viewtopic.php?p=105187#p105187
Luke Alan писал(а):
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.

How are things now? Have you already created a new Drakon editor?

Как обстоят дела сейчас? Вы уже создали новый Drakon editor?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 17:44 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
Nope, I'm still using it to build my game
Previously I just had very loose feelings for ideas of how to improve the editor, now I definitely have more concrete ideas

I don't think there is one 'killer feature' that would make DRAKON totally different, besides maybe in-editor debugging, but combined small features would be even more useful for productivity. Essentially, DRAKON editor needs a lot of small fixes and modernizations.

My current wish list is the following, and I still plan to add these features myself if no one else (Stepan Mitkin the most likely candidate) does, but it could be 2 years or 20 years before I have the free time to do so:
1) Automatic Drawing of Icons/Lines: Automatic diagram drawing of connection points using point-and-click or keyboard navigation and hotkeys (like Drakon.Tech web editor)
2) Automatic Rearrangement of Control Flow: Automatic refactoring of diagrams to arrange the control flow (yes/no) icons differently. The algorithm should automatically try and use the fewest 'branches' possible, to make the diagram more readable.
3) Collapse/Expand: Ability to see multiple diagrams on a shared main skewer (vertically). All of the diagrams in a file would ideally be shown this way, one skewer for function definitions and one for each entry point (either the first code that runs, or functions that respond to events like user input or other external triggers). Each one of these 'new skewers' would be on its own canvas ideally. By default each diagram on a shared skewer would be collapsible and expandable, like code folding in traditional text editors.
4) Static Typing: Static typing enforced by the editor, through data-validated parameters and assignment variables on their own statement icons. The implementation should get the hell out of your way, like Microsoft Excel's data validation does - a popup GUI asks you to specify the data validation type for a cell (or define your own custom one), and then checks that the cell is valid when you input something and/or restricts what you can input - this is 'Smart Structural Editing' as opposed to having to implement it inside the programming language itself. To be clear, the static typing should be done by the DRAKON editor and be language agnostic, even if the type implementations are done in each DRAKON language implementation (as an OPT in of course, it doesn't always make sense to do the extra work of type validation, just like in Excel)
5) In-editor debugging: Between each two icons, including the header icon and the end icon, on vertical lines only, there should be a hidden function call implemented behind the scenes when 'debug output' is toggled on in the editor. The file would then be simulated to run inside the DRAKON editor: each time one of the hidden function calls is called, a 'travelled here' counter in the form of a number in between diagram icons would appear, to let you know how many times that 'line' has been travelled by the program execution. Each icon should also be able to be toggled to be a break point, which stops control flow execution until you continue it, and this should be displayed visually in a similar manner to indicate to the user that the breakpoint has been reached and requires their action to continue. Coupled with being able to see how control flow is 'flowing' in your diagram visually, this will allow users to easily find:
A) Unused code in individual functions and unused functions themselves
B) Code that is not executing and where it is going wrong
C) How the logic in complicated systems is being calculated by the control flow, for reinforcing that your program is working correctly or not

6) Make Asynchronous Control Flow Explicit: Just like DRAKON did originally for synchronous code, asynchronous code in single threads should be shown diagrammatically and explicitly through a parent 'scheduler' function, so that all events come in from a single entry point: the scheduler, and are processed on diagrammatic 'queues'. This demystifies how asynchronous code in a single thread is working to the user and makes debugging easier IMO, as well as makes modeling the program easier in the first place. Each 'new thread' should have its own new scheduler on a new canvas, and a new main 'skewer' line on its own canvas. Only function calls should be on these types of canvases, not function definitions IMO - but this needs more research, thought, and planning I admit.

7) Uncalled Functions: The editor should be able to keep a cached memory of which functions are never called in the code, which persists between file opens/closes (is saved somewhere as well). The code to recheck this should only happen when a diagram is added or modified, it shouldn't blindly check all diagrams even if they haven't been modified (this would be slow for large files). This helps you see which code is potentially ready for deletion. However, since sometimes functions can be called magically, like through javascripts Eval, each diagram should have an editor-implemented feature to say 'Diagram is called magically' which overrides this automatic checker, and marks the diagram as called.

8 ) Persistent, forever undo/redo: Everything you do in a diagram file should be undoable/redoable, with complete history, forever, unless you explicitly use an option to clear the history to save disk space. History should be stored on an individual diagram level, and even deleted diagrams should be saved - with a unique ID and timestamp data for when the diagram was created, all timestamps of when it was modified and how, and a timestamp of its deletion date(s) (diagrams could potentially be deleted, reinstated, and deleted again many times). This prevents loss of work and essentially implements 'revisioning' inside the editor. It would make working with programming teams much nicer as well, they love their 'diff'/'merge' tooling, and this paves the way for that. However, as a solo developer, I haven't thought about diff/merge tooling specifically, that area needs more research, planning, and thought.

9) Bidirectional code: I've said it for a long time, and it's still true, DRAKON diagrams should be bidirectional - they should compile to some human readable format, like a more extended JSON type of data format, which describes the diagram to the editor. Editing the diagram should simultaneously edit the 'text' representation, and users should be able to perform complex regex and other manipulation to the text and have the diagram update to reflect it once it reloads the text form - if it is indeed valid text. I view this as a similar language to HTML or CSS, it's a highly targeted domain specific language for drakon diagrams, that should be language agnostic. Primarily, this makes it much easier to create DRAKON implementations for new languages and add more language-specific features in the future. It would also make implementing all of the other features on this wishlist easier.

10) Autocomplete: Like in traditional editors, normal code autocomplete would be nice

11) Smarter Build: Only diagrams that have been newly created or modified since the last 'build' should be built, not building all diagrams each time which is slow and naive.

12) UI overhaul: The entire DRAKON UI needs a modernization/overhaul, primarily to prevent taking up so much screen space. For example, the 'drakon diagram built successfully' should only be a tiny vertical message on the status bar, not show an empty problems area. Many small things like this would free up a ton of screen space in the DRAKON editor.

13) UI Hotkeys: There needs to be many, many more hotkeys, all customizable, to make working with DRAKON editor faster for pro users.

14) Find/replace should be able to use regex, and it should automatically rename diagram names on the left hand pane without you having to manually open the diagram name icon and close it to apply the change (conflicting diagram names should be shown in the problems view if a Replace operation creates duplicates)

15) Structured Editing: The editor should support structured editing, which completely removes the concept of adding whitespace. First of all, icons don't really need whitespace when created according to the rules in my screenshots. Parameters in function calls could easily be done with nicer looking GUI without using TAB indents. Whitespace can then be controlled by CSS, so different firms can style the same source code how they like. This is a concept from structural editing. It also makes making mistakes like having two consecutive spaces impossible.

16) Smart Switch Icons: Long switch statements should 'wrap' automatically to fit on the screen. This doesn't mean making any modifications to the diagram other than visually. I'm not sure exactly how this would look visually, it would just be nice to have, and it should be clear that a wrapped switch statement is actually visually just 'wrapping', as opposed to being poorly drawn. In addition, switch statements should be individually collapsible showing only the default and last option with dots in between representing 'collapsed' options, so that centering a diagram in the canvas doesn't take a long switch icon set into consideration.

17) No syntax: Like DrakonJS and DrakonLUA, there should be no syntax, no parentheses and other syntax. Just names of things and structured forms. Syntax can still be there, it is just abstracted away into icons and structural forms using CSS styles instead of tabs/whitespace. In addition, for loops and other types of loops should have their syntax removed and replaced with CSS GUI forms and structured editing, similar to how tools like Unity Bolt or Unreal Engine Blueprints do so. I also think there should be a universal "Iterator" icon which doesn't care if you specify a foreach collection, a Map, an array, and so on. It should be up to the language implementor to make them all work with a single iterator icon (like the current foreach icons, but with arrow loops as I've talked about previously, going to the left rather than the right, as opposed to being without arrows).

18) Compact Icons: Icons should be more compact in my opinion, just a little bit, with less wasted white space inside the icon borders as well. The primary driver of diagram readability for me is being able to see the entire diagram on screen, without scrolling. So the more we can fit on a screen due to less wasted whitespace everywhere, the better. However, the lines between icons should still be visible - just slightly less tall or wide, to maximize and optimize the amount of icons visible at one time.

19) Structured Names: After structured editing feature basics are implemented, the next step would be to make variable/diagram/parameter names themselves structurally edited, so that names could include dashes, spaces, or something more readable than underscore_names or camelCaseNames, which are abominations carried over from text-based programming.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 18:47 

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

я не думаю , что есть один «убийца особенность» , что бы сделать DRAKON совершенно другой, не считая отладки в редакторе, но объединенные небольшие функции были бы еще более полезны для повышения производительности.
По сути, редактор ДРАКОН нуждается в большом количестве мелких исправлений и модернизаций.

Мой текущий список желаний следующий, и я все еще планирую добавить эти функции сам, если никто другой (Степан Миткин, наиболее вероятный кандидат) не сделает этого, но может пройти 2 или 20 лет, прежде чем у меня появится свободное время для этого:

1) Автоматическое рисование значков / линий: автоматическое рисование схем точек подключения с использованием указателя и щелчка или навигации с клавиатуры и горячих клавиш (например, веб-редактор Drakon.Tech)

2) Автоматическая реорганизация потока управления: автоматический рефакторинг диаграмм для организации управления поток (да / нет) иконки по-разному. Алгоритм должен автоматически пытаться использовать как можно меньше «ветвей», чтобы сделать диаграмму более читаемой.

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

4) Статическая типизация: статическая типизация, применяемая редактором с помощью проверенных данных параметров и переменных присваивания на их собственных значках операторов. Реализация должна убираться с вашего пути, как это делает проверка данных Microsoft Excel - всплывающий графический интерфейс просит вас указать тип проверки данных для ячейки (или определить свой собственный), а затем проверяет, что ячейка действительна, когда вы что-то вводите и / или ограничиваете то, что вы можете вводить - это «умное структурное редактирование», в отличие от необходимости реализовывать его внутри самого языка программирования. Чтобы было ясно, статическая типизация должна выполняться редактором DRAKON и не зависеть от языка, даже если реализации типов выполняются в каждой реализации языка DRAKON (в качестве OPT, конечно, не всегда имеет смысл делать дополнительные работа проверки типа,

5) Отладка в редакторе: между каждыми двумя значками, включая значок заголовка и значок конца, только на вертикальных линиях, должен быть скрытый вызов функции, реализованный за кулисами, когда в редакторе включен «вывод отладки». Затем файл будет смоделирован для запуска в редакторе DRAKON: каждый раз, когда вызывается один из вызовов скрытых функций, появляется счетчик `` пройдено сюда '' в виде числа между значками диаграммы, чтобы вы знали, сколько раз эта «линия» пройдена при выполнении программы. Каждый значок также должен иметь возможность переключаться на точку останова, которая останавливает выполнение потока управления, пока вы не продолжите его, и это должно отображаться визуально аналогичным образом, чтобы указать пользователю, что точка останова достигнута и требует их действия. продолжить.

A) Неиспользуемый код в отдельных функциях и сами неиспользуемые функции
B) Код, который не выполняется и в котором он работает неправильно
C) Как логика в сложных системах вычисляется потоком управления для подтверждения того, что ваша программа работает правильно или нет

6) Сделайте асинхронный поток управления явным: так же, как DRAKON изначально сделал для синхронного кода, асинхронный код в отдельных потоках должен отображаться схематично и явно через родительскую функцию «планировщик», чтобы все события поступали из одной точки входа: планировщика , и обрабатываются в схематических «очередях». Это проясняет, как асинхронный код в одном потоке работает для пользователя, и упрощает отладку IMO, а также упрощает моделирование программы в первую очередь. Каждый «новый поток» должен иметь свой собственный новый планировщик на новом холсте и новую основную линию «вертела» на своем собственном холсте. На этих типах холстов должны быть только вызовы функций, а не определения функций IMO - но это требует дополнительных исследований, размышлений и планирования, я признаю.

7) Не вызываемые функции: редактор должен иметь возможность хранить кэшированную память, функции которой никогда не вызываются в коде, которая сохраняется между открытием / закрытием файла (также где-то сохраняется). Код для повторной проверки этого должен происходить только при добавлении или изменении диаграммы, он не должен слепо проверять все диаграммы, даже если они не были изменены (это будет медленным для больших файлов). Это поможет вам увидеть, какой код потенциально готов к удалению. Однако, поскольку иногда функции могут вызываться волшебным образом, например, через javascripts Eval, каждая диаграмма должна иметь реализованную редактором функцию, чтобы сказать «Диаграмма вызывается волшебным образом», которая отменяет эту автоматическую проверку и отмечает диаграмму как вызванную.

8) Постоянная, навсегда отменить / повторить: все, что вы делаете в файле диаграммы, должно быть отменено / повторено, с полной историей, навсегда, если вы явно не используете опцию очистки истории для экономии места на диске. История должна храниться на отдельном уровне диаграммы, и даже удаленные диаграммы должны быть сохранены - с уникальным идентификатором и данными о времени создания диаграммы, всеми метками времени, когда она была изменена и как, а также меткой времени ее удаления ( s) (диаграммы потенциально могут быть удалены, восстановлены и удалены снова много раз). Это предотвращает потерю работы и, по сути, реализует «доработку» внутри редактора. Это также сделало бы работу с командами программистов намного приятнее, им нравятся их инструменты 'diff' / 'merge', и это прокладывает путь для этого. Однако, как индивидуальный разработчик, я не

9) Двунаправленный код: я говорил это давно, и это все еще верно, диаграммы DRAKON должны быть двунаправленными - они должны компилироваться в какой-то удобочитаемый формат, например, более расширенный тип формата данных JSON, который описывает диаграмму для редактор. Редактирование диаграммы должно одновременно редактировать «текстовое» представление, и пользователи должны иметь возможность выполнять сложное регулярное выражение и другие манипуляции с текстом и обновлять диаграмму, чтобы отразить ее после перезагрузки текстовой формы - если это действительно действительный текст. Я рассматриваю его как язык, похожий на HTML или CSS, это сильно ориентированный предметно-ориентированный язык для диаграмм драконов, который должен быть независимым от языка. В первую очередь, это значительно упрощает создание реализаций DRAKON для новых языков и добавление дополнительных языковых функций в будущем.

10) Автозаполнение: как и в традиционных редакторах, нормальное автозаполнение кода было бы неплохо

11) Умная сборка: должны быть построены только диаграммы, которые были недавно созданы или изменены с момента последней `` сборки '', а не строить все диаграммы каждый раз, что медленно и наивно .

12) Капитальный ремонт пользовательского интерфейса: весь пользовательский интерфейс DRAKON нуждается в модернизации / капитальном ремонте, в первую очередь, чтобы не занимать так много места на экране. Например, «диаграмма дракона построена успешно» должна быть только крошечным вертикальным сообщением в строке состояния, а не отображать пустую область проблем. Многие подобные мелочи освободили бы тонну экранного пространства в редакторе ДРАКОН.

13) Горячие клавиши пользовательского интерфейса: должно быть много-много дополнительных горячих клавиш, все настраиваемые, чтобы сделать работу с редактором DRAKON более быстрой для профессиональных пользователей.

14) Поиск / замена должен иметь возможность использовать регулярное выражение, и он должен автоматически переименовывать имена диаграмм на левой панели без необходимости вручную открывать значок имени диаграммы и закрывать его, чтобы применить изменение (конфликтующие имена диаграмм должны отображаться в вид проблем, если операция Replace создает дубликаты)

15) Структурированное редактирование: редактор должен поддерживать структурированное редактирование, которое полностью исключает идею добавления пробелов. Во-первых, значки действительно не нуждаются в пробелах, когда они создаются в соответствии с правилами на моих скриншотах. Параметры в вызовах функций могут быть легко выполнены с более красивым графическим интерфейсом без использования отступов TAB. Затем пробелами можно управлять с помощью CSS, поэтому разные фирмы могут стилизовать один и тот же исходный код по своему усмотрению. Это концепция структурного редактирования. Это также делает невозможными такие ошибки, как наличие двух последовательных пробелов.

16) Значки умных переключателей: длинные операторы переключения должны автоматически «переноситься» по размеру экрана. Это не означает внесения каких-либо изменений в диаграмму, кроме как визуально. Я не совсем уверен, как это будет выглядеть визуально, было бы просто неплохо иметь, и должно быть ясно, что завернутый оператор switch на самом деле визуально просто «обертывает», а не плохо прорисовывается. Кроме того, операторы switch должны быть индивидуально сворачиваемыми, показывая только последний вариант по умолчанию и последний вариант с точками между ними, представляющими «свернутые» варианты, чтобы при центрировании диаграммы на холсте не учитывался длинный набор значков переключателя.

17) Нет синтаксиса: Как и DrakonJS и DrakonLUA, не должно быть синтаксиса, скобок и прочего синтаксиса. Просто названия вещей и структурированные формы. Синтаксис все еще может присутствовать, он просто абстрагируется до значков и структурных форм с использованием стилей CSS вместо вкладок / пробелов. Кроме того, для циклов for и других типов циклов следует удалить синтаксис и заменить его формами графического интерфейса пользователя CSS и структурированным редактированием, аналогично тому, как это делают такие инструменты, как Unity Bolt или Unreal Engine Blueprints. Я также думаю, что должен быть универсальный значок «Итератор», который не заботится о том, указываете ли вы коллекцию foreach, карту, массив и т. Д. Разработчик языка должен сделать так, чтобы все они работали с одним значком итератора (как текущие значки foreach, но с петлями стрелок, о которых я говорил ранее,

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

19) Структурированные имена: после того, как будут реализованы основы функции структурированного редактирования, следующим шагом будет структурное редактирование самих имен переменных / диаграмм / параметров, чтобы имена могли включать тире, пробелы или что-то более читабельное, чем underscore_names или camelCaseNames, которые являются мерзости, перенесенные из текстового программирования.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 19:05 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
I am going to create specially for you the definite forum region (partition) such as
Цитата:
Проект «Язык Дракон–ПЛК» Алексея Муравицкого
Please, tell me your own title for it

Maybe
Цитата:
"Game creating in Drakon-charts" project by Luke Alan
What do you think about it?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 21:39 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
I would rather not have my own section

The number of posts and members here is already scarce, and my updates are pretty rare for this project, it's most likely to be seen by others in this section.

Also, just because I'm making a game, my suggestions and use of DRAKON would be identical for any other app or program, they aren't related to gaming, that just happens to be what I'm using it for.

For example if I wanted to build software for a spacecraft, I'd do it according to the same rules/standards and want the same features.

I've already wished and planned to build a new DRAKON editor itself in DrakonJS, with some of these feature ideas, before the hard task of creating a DSL for diagrams, but not a single line of code or bit of work is done for this, and may never be done, or may happen decades later.. so it's premature to make a section for that yet as well.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Пятница, 23 Июль, 2021 22:45 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
You have created several topics in this forum. And nobody knows where they are. It isn't user-friendly.

When a forum participant or guest (your reader) is reading the one of your topic he (she) don't know about the other your topics.
It is not good. It is bad.

The section is a good idea as it unites the all your separate topics in one place, in one section.
Your readers will be glad as they will get an opportunity to know more about your interesting plans, decisions and suggestions.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Суббота, 24 Июль, 2021 03:40 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
In my opinion it's a trade off, yes if every thread creator with unique ideas gets their own sub forum, you can find related threads easy, but you can't find the threads in the first place as easy, because you have to navigate to dozens of sections which most people won't have the time and patience to do.

It is like having a website landing page, versus an individual page for every person who writes on the website - who has the time to click the names of every person when they have no idea who it is and read their threads one by one? Far better to have all authors post articles by date on a single landing page, moved to the top again when a reply is made. Yes it's unorganized by author, but much more discoverable for everyone.

When it makes sense to branch into a subtopic is when there are so many new posts per day, casual readers cannot keep up with all of the new posts in a day. Then, you should divide content by topic somehow, not authors. Such as 'health' vs 'politics'. If there are still too many new threads a day in a subsection, divide again into 'medicine' and 'food' for example.

That isn't a problem on this forum, the number of new threads per day is very low. This is just my perspective of course, and at some point it all boils down to a subjective balancing of the pros and cons for each way.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Суббота, 24 Июль, 2021 11:37 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Since you are against special sub forum, let's leave it as it is.
_________________________________

Your work is very interesting.
If it's not a top secret, please, tell us more about yourself.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Воскресенье, 25 Июль, 2021 00:41 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
About me: I'm just a long time hobby scripter/programmer trying to make games, but the types of games I make aren't well suited to unity, unreal engine, or even text based programming. They're more like rule engines because there's so many complex rules for my custom board games, and so there doesn't really exist a good way to visually merge a bunch of rules with program functions, other than Drakon. Even in drakon, complexity will blow up though if rigid principles aren't followed. I used to have functions that would take up 4-5 screens of my very large monitor, and be slow to pan around inside the editor, not to mention how much time it took to understand the logic. However, even though it was harder to do, it was obviously 10x easier to do in Drakon than in code. I had given up many times making my game in text IDE's, because the complexity was too daunting.

I'm sure there are some very smart people that could do it, just not me, I'd rather be smart about keeping things simply structured, than smart enough to figure out complex structures.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Воскресенье, 25 Июль, 2021 08:22 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Luke Alan писал(а):
Обо мне:

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

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

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

Однако, несмотря на то, что это было труднее сделать, это было очевидно в 10 раз легче сделать в Drakon, чем в коде. Я много раз отказывался от создания своей игры в текстовых IDE,

Я уверен, что есть очень умные люди, которые могли бы это сделать, но не я, я бы предпочел, чтобы вещи были просто структурированными, чем достаточно умными, чтобы определять сложные структуры.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Понедельник, 26 Июль, 2021 02:52 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
I've put together a quick guide on
how to refactor complex 'if icon' logic
into only two branches and minimum
number of functions.

It is not trivial to do so, at least
it seems to me, although it would be
trivial for an automatic DRAKON editor
to do once taught how.
This automatic feature has the potential
to speed up productivity simply by
automating this refactoring process.

Let's take the simplest non-trivial example:

Я собрал краткое руководство о том,
как преобразовать сложную логику if icon
только в две ветви и минимальное
количество функций.

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

Возьмем простейший нетривиальный пример:

Изображение

See the next post.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Понедельник, 26 Июль, 2021 03:00 

Зарегистрирован: Среда, 21 Октябрь, 2020 21:13
Сообщения: 32
In step 1, we have three branches. If we want to simplify to two branches, we can follow these logical steps, which should in theory work for any multi-branch logic:

To get from step 1 to step 2, find the longest possible path, which is the one requiring the most number of icons, in the logic and rearrange the control flow so that it is moved to the main skewer, or happy path. In step 1, the longest path requiring the most icons is when a, b, and c all are Yes.

There may be more than one path that is the 'longest', in this case try to choose the longest path that has all of the Yes or No the same orientation on the main skewer. Beyond that it does not matter if they are all oriented No or Yes on the main skewer, as long as they are the same. If they cannot all be oriented the same way, orient as many as possible the same way.

In addition to this, terminate each one in the simplest manner - with its own return icon for every if icon, to keep things simple.

To get from step 2 to step 3, combined from left to right whenever there are two 'return true' or two 'return false' in a row, as shown in step 3.

Now again we have 3 branches, we should have the same number of branches in step 3 (or fewer) than we did in step 1.
At this point, we have no option left except to move the innermost pair of branches to their own function.

To get from step 3 to step 4, pass the parameters needed to calculate a new boolean, in this case, d, to a new function and use it to reduce the example function into only two branches. Now, we need to paste what we removed from the example function to our first new function, child_1, and use it to calculate the d boolean.

These steps would just be repeated for more complicated control flows, but they should apply to any complex control flow (hopefully). This is all stuff I worked out by myself, so it's by no means guaranteed.
________________________________

A simplified version of drakon best practices:

The only place if icons, switch statement icons, and loop icons should exist is on the main skewer, or the left-most vertical line.

Action icons can exist on any vertical line.

In addition, whenever a vertical line terminates somewhere besides right above an End icon, everything below that vertical line should be refactored into its own function, or the vertical line should be refactored to be extended further down to the end icon.

This naturally guides toward the 'two branch' rule, without needing to formally state it. However, with these simplified rules, even step 3 would be valid. I think it's a subjective decision if refactoring from step 3 to step 4 and 5 is worth it. For complex logic I think it is, when the logic is only '3 branches' total in the big picture, it may be worth it just to leave it at three branches, because all of the control flow is at least directed from the happy path only.

Case icons are exempt from the rule, only the 'switch' icon needs to be on the main skewer, also known as the happy path.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Diagram Best Practices
СообщениеДобавлено: Понедельник, 26 Июль, 2021 09:03 

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

Чтобы перейти от шага 1 к шагу 2, найдите максимально длинный путь, который требует больше всего количество значков, в логике и переставьте поток управления так, чтобы он переместился на основную шпажку или счастливый путь. На шаге 1 самый длинный путь, требующий наибольшего количества значков, - это когда a, b и c все имеют значение «Да».

Может быть несколько путей, которые являются «самыми длинными», в этом случае попробуйте выбрать самый длинный путь, который имеет одинаковую ориентацию «Да» или «Нет» на главном вертеле. Кроме того, не имеет значения, ориентированы ли все они на главный шампур: «Нет» или «Да», если они одинаковы. Если все они не могут быть ориентированы одинаково, сориентируйте как можно больше людей одинаково.

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

Чтобы перейти от шага 2 к шагу 3, комбинируйте слева направо всякий раз, когда в строке есть два «return true» или два «return false», как показано на шаге 3.

Теперь у нас снова есть 3 ветви, у нас должно быть то же самое. количество ветвей на шаге 3 (или меньше), чем на шаге 1.
На данный момент у нас нет другого выбора, кроме как переместить самую внутреннюю пару ветвей в их собственную функцию.

Чтобы перейти от шага 3 к шагу 4, передайте параметры, необходимые для вычисления нового логического значения, в данном случае d, новой функции и используйте их, чтобы сократить пример функции только до двух ветвей. Теперь нам нужно вставить то, что мы удалили из функции примера, в нашу первую новую функцию, child_1, и использовать ее для вычисления логического значения d.

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

Упрощенная версия лучших практик драконов:

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

Иконки действий могут располагаться на любой вертикальной линии.

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

Это естественным образом ведет к правилу «двух ветвей», без необходимости его формально формулировать. Однако с этими упрощенными правилами будет действителен даже шаг 3. Я думаю, что это субъективное решение, стоит ли рефакторинг от шага 3 к шагу 4 и 5. Я думаю, что для сложной логики это так, когда логика состоит всего из `` 3 ветвей '' в общей картине, возможно, стоит просто оставить ее на трех ветвях, потому что весь поток управления, по крайней мере, направлен с счастливого пути Только.

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


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

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


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

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


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

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