Обсуждение в этой теме вновь подняло вопрос о недостаточности возможностей техноязыка для программирования. Однако пока не получилось конструктива: лейтмотив прозвучавших высказываний - визуализированная программа есть исходный чертёж на языке ДРАКОН-Х плюс "ещё что-то, что умом не понять и аршином не измерить"
т.е. какие-то возможности, которых нехватает семейству техноязыков (гибридных) и которые непонятно как туда ввести. Так у нас получается то, на что Илья в своём докладе указывал как на "заклинательство" и от чего считал необходимым (и возможным) уходить.
Так, было сказано
в этом сообщении:
Info21 писал(а):
Я тоже не верю, что достаточно серьезную программу непрограммист сможет разработать на Драконе, если не сможет на Обероне. Ту же быструю сотрировку.
Ни логику, ни граничные условия, ни вырожденные случаи Дракон не отменяет.
Да, какие-то особенности программирования (прежде всего, видимо, системного/распределённого) в действующем стандарте техноязыка не учтены - прежде всего, как уже по-моему говорили, потому, что они не потребовались для программирования тех задач, под которые делалась технология ГРАФИТ и языки ДРАКОН-ФЛОКС - но мало ли какая система общего назначения вырастала из специализированной?
Конечно, информатическая субкультура, как и культура в целом, включает, кроме науко/техники и искусства, также и веру (по крайней мере, если принять т. зр. Рериха
), но наверное, вопрос "можно ли визуализировать программу, если можно написать её чистым текстом" не тот, который нужно делать "догматом инфорелигии"? Всё-таки это стоит относить к научной сфере и потому проверять - давайте визуализируем быструю сортировку или докажем, что визуализация "достаточно серьёзной" программы невозможна в принципе, какой визуальный язык не создавай для этого
) Только серьёзность должна, видимо, приобрести математические/информатические очертания?
Конструктивный взгляд - семейство импер-деклар-языков, вырастающее из шампур-метода, должно не отменять, а включать эти и другие составляющие полноценного программирования. Что-то должно реализоваться через визуальный синтаксис, что-то через текстовый, что-то - и так, и так. Отмеченный в цитате перечень, "чего не отменяет ДРАКОН", возможно, неполон - это виднее программистам. Поэтому давайте:
* определять перечень того, что нужно для полноценного гибридного программирования на базе одного прогязыка (за базовый принят Оберон, в перспективе - Активный, не так ли?);
* вводить это в стандарт семейства техноязыков (что-то в импер-язык, что-то - во вновь создаваемый деклар-язык).
Всё это обсуждалось ведь уже в том или ином виде - в частности, мной подробнее изложено
в этом сообщении - а делается ли что-то кем-то, так и непонятно...
И ещё один аспект, вновь затронутый
в этом сообщении:
igor писал(а):
Я считаю, что текстовый синтаксис не принадлежит языку Дракон, потому что грамматический разбор и трансляция текстоэлементов должна выполняться инструментальными средствами тех языков, на которых они написаны.
Замечу, что сказанное не уменьшает ценности языка Дракон. Просто его нужно использовать по назначению, а не позиционировать как язык программирования (да ещё реального времени).
Я бы это уточнил так: визуальному гибридному языку (напр. ДРАКОН-Оберон-2) принадлежит ВЕСЬ синтаксис описания программ - и текстовый, и нетекстовый - но из описания на таком языке (комплекта исходных чертежей, включающего импер- и деклар-части) внутри поддерживающей язык РДП-системы генерируется исходный текст (напр. на Обероне), и трансляция должна выполняться уже с него - существующим компилятором. Этот компилятор действительно не принадлежит РДП-системе (в том смысле, что не должен разрабатываться специально для неё) - напротив, гибридный язык в этой системе реализуется так, чтобы получать по чертежам правильные тексты, без ручного "шаманства" способные пройти трансляцию.
Сказанное полностью относится и к реальному времени - берём рабочий прогязык РВ (напр. Активный Оберон) и делаем то же самое для него.
Тогда не надо будет требовать от сочинителя-непрограммиста, чтобы он изучал ту часть прогязыка исходного текста (Оберона-2/Активного), которая в изоморфном языке исходных чертежей (ДО-2/ДАО) реализована визуально. Хотя не вызывает возражений, что сочинителю-программисту язык исходного текста надо знать полностью - это опять-таки ИТ-культура.