Нет, я до сих пор использую его , чтобы построить свою игру
Раньше я просто был очень рыхлые чувства к идеям о том , как улучшить редактор, теперь у меня определенно есть более конкретные идеи ,
я не думаю , что есть один «убийца особенность» , что бы сделать 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, каждая диаграмма должна иметь реализованную редактором функцию, чтобы сказать «Диаграмма вызывается волшебным образом», которая отменяет эту автоматическую проверку и отмечает диаграмму как вызванную.
Постоянная, навсегда отменить / повторить: все, что вы делаете в файле диаграммы, должно быть отменено / повторено, с полной историей, навсегда, если вы явно не используете опцию очистки истории для экономии места на диске. История должна храниться на отдельном уровне диаграммы, и даже удаленные диаграммы должны быть сохранены - с уникальным идентификатором и данными о времени создания диаграммы, всеми метками времени, когда она была изменена и как, а также меткой времени ее удаления ( 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, которые являются мерзости, перенесенные из текстового программирования.