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