DRAKON.SU

Последнее время всё чаще возвращаюсь к теме языка ДРАКОН, пересматриваю различные материалы по этой теме.
Отсюда у меня вышла закономерная теория.
1) Для описания парадигмы ООП в документации единственным решением остается UML, который также реализует возможность описывать алгоритмы, но крайне неэстетично, в отличии от языка ДРАКОН.
Отсюда вытекает версия о соединении языка ДРАКОН с языком UML в одной программной оболочке, где взяв из каждого лучшее можно получить полноценную среду разработки программного обеспечения.
2) Язык ДРАКОН хоть и реализует возможность структурированно подавать алгоритм по методологии разделения задач, очень слабой стороной его остаётся потоковое программирование. Предлагаю также пересмотреть вопрос об организации потоковой разработки в ДРАКОНе. Идеи для этого можно взять из того же языка UML, но встраивая его в схемы ДРАКОНа.
3) Большое количество устройств поддерживают основные языки программирования С++, JS и Python, они пригодны для написания встраиваемых, мобильных, десктопных, серверных, спутниковых приложений. Иными словами, они работают практически везде.
Как это относится к языку ДРАКОН? В среде разработки можно и нужно реализовать возможность не только генерировать код, но и собирать его в готовые приложения, отлаживать и тестировать.
Эта среда(в идеале) может дать весьма крупные плюсы к любому процессу разработки:
- однажды написанный код или модуль будет работать на любой платформе, транслятор сам решит в какой язык ему его преобразовывать
- комментирование и разбиение на ветки будет у программиста в обязательстве(!) для более удобного чтения его же программы им или другими специалистами
- переменные, классы, базы данных и потоки будут реализовываться весьма простым образом, не нужно будет учить разные библиотеки и конструкции конкретного языка чтобы просто запустить параллельную работу двух объектов без ошибки единовременного доступа к одной области памяти или взаимной блокировки
- появление нового уровня определения ошибок - эргономических - например, если программа сочтет что ваша подзадача слишком крупная и её можно разбить на несколько более мелких. К таким ошибкам можно отнести весьма вредную рекурсию, единовременный доступ к памяти, некомментированные переменные, объекты, задачи и др.
- процесс отладки приобретет ещё одну возможность: проверка не всей функции, а одной конкретной её ветки, что также ещё более упростит возможность тестирования
- в целом весь процесс разработки будет одновременно и процессом частичного документирования, что не может не радовать
- среда программирования может также стать средой моделирования задач в физике, электронике, медицине и тп, что расширит возможности различных специалистов и ещё более понизит порог вхождения в программирование для новичков
- один общий универсальный синтаксис, работающий везде
В таком случае уже мы уйдем от понятия программирования, к понятию математического аппаратного моделирования задач. Я считаю, что это правильный подход. Программист в первую очередь должен знать, что код решает задачу, а данная среда всем своим видом будет напоминать ему об этом.

P.S. Графическое моделирование, известное как Blueprints в Unreal Engine не соответствует полному пониманию математической логики и в ряду аспектов(как, например, задание логики поведения персонажей) является затруднительным для анализа простым взглядом. Может быть оно в данной отрасли будет являться лучшим серьёзным визуальным решением, однако в качестве именно универсального языка он значительно проигрывает связке ДРАКОН + UML.

Прокомментируйте пожалуйста, справедливы ли мои суждения?

Даниил, вы выступили с крупной инициативой. Поздравляю и приветствую вас.

Если ваша идея окажется верной, вас ждет большое будущее.

Собираетесь ли вы реализовать вашу идею? Может быть, у вас уже есть наработки, которые можно пощупать? Или это чисто теоретические рассуждения?

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

Особенно мне понравилась мысль: "- однажды написанный код или модуль будет работать на любой платформе, транслятор сам решит в какой язык ему его преобразовывать".
Это здорово!
Но и остальные мысли полностью поддерживаю.
Нам сейчас очень не хватает современной IDE ДРАКОН.

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

Это слишком крупная задумка для курсовой, и потому хороший способ её завалить, либо прототип будет слишком прототипистый. Лучше сделать ТЗ поскромней и реалистичней, например, до просто ещё одного визуального редактора без трансляции.

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

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

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

Даниил, ваша тема очень интересная.
Но. Она содержит мало информации. Очень мало.
По сути, это лишь заявка на тему.
Тема не раскрыта.
К сожалению, нет никакой конкретики

Посмотрите, как раскрывает свою тему Михаил Кузьмин
viewtopic.php?f=62&t=6850

Посмотреть стоит лишь в том смысле, чтобы увидеть, как делать не надо. Не любая деятельность лучше ничего не делания.

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

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

В прототипе данная идея реализована в любом случае не будет, она - на потом.

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

Пока файл очень сырой, я ищу информацию, но вот основные задумки.
Проект делится на составляющие:

ИНТЕРФЕЙС – внешний вид приложения (GUI-интерфейс, графика игры, электрическая схема устройства с программируемыми микросхемами и тп).
Консоль используется только для отладки отдельных модулей и не имеет интерфейса.
В прототипе будет только консоль.
(на основе визуального редактора форм Visual Studio и САПР Proteus).

КОМПОНЕНТ – скетч с описанием изображений, аудио, видео, дизайна компонентов интерфейса, материал и т.п.
(на основе blueprints ue4 и редактора компонента)

СТРУКТУРА – связанные скетчи с описанием переменных, типов данных, классов, структур, шапок функций.
(на основе ГОСТ 19.701-90, UML и СУБД)

АЛГОРИТМ – скетч с описанием поведения функции
(на основе языка ДРАКОН)

ПРОГРАММА – скетч с описанием программных инструкций
(на основе blueprints ue4 и графического языка описания логики как в quartus)