Для начала - ответ из другой ветки на вопрос скорее этого топика:
...
Статья о Драконе в Википедии несколько раз удалялась и восстанавливалась.
Она восстанавливалась в результате протеста специалистов.
Один из таких специалистов, в частности, писал (на странице обсуждения):
http://ru.wikipedia.org/w/index.php?tit ... 1%8B%D0%BA)&oldid=39151287
Цитата:
...
Мне кажется, что прежде, чем что-то удалять, надо хотя бы прочитать, что про это написано. Не говоря уж об том что есть книжка Алистера Коберна "Современные функциональные требования", где выражаются похожие мысли.
..................................................................................
Из этого текста я понял, что в книге Алистера Коберна "Современные функциональные требования" есть мысли, похожие на высказанные мной.
Книгу Коберна я не видел. Но мне очень интересно, что там сказано.
Вы много читаете и обладаете большой эрудицией, может быть, Вам попадалась эта книга?
Если да, просьба поделиться знаниями.
Нет, я о ней услышал на Обероне впервые...
С торрентами не связываюсь, так что ссылка для меня неактуальна...
Одно соображение только по бибописаниям высказать могу - как бы не оказалось, что там гл. обр. о том, "как нам всё-таки описать программы на юмле"...
а на сию тему после 2002 года есть результаты... у тех же Поликарповой и Шалыто описанные (имею в виду разные "прецизионные" и "исполнимые" юмли, прежде всего в
списке литературы перечисленные).
И теперь о статье можно. Прежде всего - о
замечании Викифаната. Честно говоря, мне бы нечего было ответить на него... ибо не могу не согласиться. Техноязык - действительно представление не всего содержания прогязыка, а лишь его импер-части.
Ещё раз повторю - это если не "хитрить", допуская "всё, что угодно в качестве дракон-комментариев и/или примечаний к дракон-вершинам". А следовать исходной идее Владимира Даниеловича, выраженной в классификации знаний, отчуждаемых программой. И независимо в более общей форме - Акимовым - см. в этом посте.
На это указывал и Илья:
Info21 писал(а):
Мне один раз И.Е. кое-что в плане математики показал, и возникло впечатление, что там что-то есть. Из-за этого лично для меня интрига пока сохраняется.
Но пока это что-то не будет явлено четко и ясно, въезжать в это дело больше не буду пытаться.
Я основную идею называю "двумерным структурным программированием".
Кратко, как вижу этот вопрос:
1) Примем понимание, что алгоритм - это шаблон возможных процессов (последовательностей событий).
(Подобие с понятием грамматики формального языка).2) Далее обсуждаем только поток управления в программе и способ его записи. Берём самую развёрнутую и простую форму - дерево (древесная развёртка алгоритма, в терминах школы Ершова). Т.е. в случае развилки по условию мы уже никогда не соединяемся, а просто повторяем на каждой ветке одинаковые окончания. В случае повтора действий образуются потенциально бесконечные рекурсивные окончания. (
Это - такая довольно естественная форма записать "грамматику на возможные процессы". У Хоара в Теории последовательных процессов символически то же самое).3) Тогда всякие разные управляющие конструкции в программах лично я представляю (для себя) как форму компактной записи (упаковки) таких деревьев. Обычное, текстовое структурное программирование - это упаковка в линейно-блочную последовательность (последовательность блоков 1 вход - 1 выход). Возможны другие формы упаковки, одним из которых является ДРАКОН.
...
В общем, реально и для типов, и для исполнителя нужны свои языки "графики и текста/таблиц". Что и делает, скажем, Ярослав постепенно...
В общем, чтобы статью править - нужно исходить из некоей концепции "формально-эргономичной визуализации".
И тут можно выделить некоторые проблемы более общие, чем в
этом посте. Те можно решить относительно эволюционно - хотя бы
так.
А эти проистекают из самой т. зр. на формализацию. Вижу такие "методические шероховатости":
1) Чрезмерное ограничение в тех или иных случаях области решения.
2) Нет ограничения обобщений частных решений.
Они ведут к следующим конкретным проблемам:
1) Неполное и неточное представление формализуемого.
2) Отделение "эргономичности" от "формальности".
Первое проявляется как раз в отвлечении от неимперативных частей отчуждаемого знания о деятельности, "уходе" от средств её информатически строгой визуализации. Причём, если в "Как улучшить..." ещё говорилсь (на с. 183), что величины нужно систематически описывать, то в "Мудреце" (на с. 734) уже утверждается: "...для процедурных знаний - ДРАКОН, для декларативных - ГРАФ.". А ведь ГРАФ - это далеко не язык представления "абстрактных типов" величин информоделей (в т.ч. программ). Как можно видеть из выдержки в
этом посте, это язык схем-классификаторов понятий естественного языка. Можно и от него прийти к языку "схем абстрактных типов"... только при этом всё равно получается, скажем, АТ-язык, как он описан
здесь и употреблён в
этой задаче...
Хорошо ещё, что говорится "в первом приближении"... однако второго с 2007 года не появилось, пока кто-то не задумался - а как же определить графит-запись реального прогязыка точно, без "хитростей"?..
Второе связано с "неформальностью", предлагаемой сочинителю. В частности, неучётом (это, исходя из топика
этой темы, наверное, ещё мягко сказано) формальных методов сочинения маршрутной структуры. Включая определение как схемы, так и текста её вершин (прежде всего условных, конечно). Кроме того, пока мало математических приложений визуализации.
Вообще пока впечатление - что логику и математику можно "обходить" и в программировании "по шампуру", и в допрограммной визуализации... пока когда-то в будущем не будут найдены средства эргономизации. Что для "кризисных" сфер формализации (которых всё больше) принципиально неверно.
Правда, кажется, начинается движение... но если не будет признания необходимости учёта математики - оно не будет систематическим.
По поводу замечаний Романа М. - тут уже нетрудно найти спектр приложений. Развитие реализаций идёт так, что я на
этой странице уже не поспеваю отражать...
Будут ли все они сочтены в Википедии за АИ - конечно, вопрос... но уже больше не к дракон-сообществу...
Не принимая это во внимание - можно, конечно, просто переделать статью "для проформы". Но если не скорректировать "парадигматические установки", обозначенные выше - как бы она не задала вектор, противоречащий реальной гарантоспособности. Смысл которой обозначен, скажем,
здесь...
P.S. Конкретное обсуждение статьи, как видно, плавно переместилось в
эту ветку... название которой не совсем отражает такой топик.