В этом сообщении изложена Часть 5, в которой представлены ответы Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», изложенные на 5-й странице форума.
Примерно через десять дней последует Часть 6, в которой я продолжу отвечать на вопросы и критические замечания.
С глубоким уважением Владимир Паронджанов
Часть 5. Ответы Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», изложенные на 5-й странице форума.Ярослав Романченко Суббота, 15 Март, 2008 12:51 Всем участвующим в обсуждении в качестве разминки рекомендую попробовать представить какую-нибудь сложную задачу с большим количеством циклов и ветвлений в виде Дракон-схемы. Если всё сделаете правильно, увидите насколько понятнее станет алгоритм.
Ответ ПаронджановаПолностью поддерживаю предложение уважаемого Ярослава. Развивая его мысль, хочу высказать пожелание. Было бы неплохо, если бы созданные участниками дискуссии дракон-схемы были где-то выложены для всеобщего обозрения и критики. В таком случае участники дискуссии могли бы сообща обсуждать эти дракон-схемы, оценивать их, выискивать недостатки и достоинства.
Дескать, вот это хорошо. А вот это плохо. Тут же бы рождались предложения — как можно устранить погрешности РЕАЛЬНЫХ дракон-схем. Чтобы сделать их совершеннее, качественнее, лучше.
ORG100H Четверг, 20 Март, 2008 17:13 Я целиком поддерживаю Дракон. Наверное, потому, что что-то подобное придумал и сам. В больших проектах на языке ассемблера первые 1000 строк пишутся за пару дней. И если вдруг случается на пару недель оторваться от кодирования, то потом смотришь на свой код в 1000 строк как баран на новые ворота. И это при том, что исполняемый код я без жалости комментирую, а географию данных иллюстрирую.
Вот уже год обдумываю трехмерную структуру, подобную Дракону для документирования проектов. А здесь вдруг встречаю предельно логичное и четкое изложение двумерного представления для исполняемого кода.
Вот отсюда мой вопрос В.П[аронджанову]. Что можно предложить для двумерного представления структур данных? Как визуально связать двумерные структуры данных с двумерными структурами исполняемого кода? Реально остаться в 2D?
Ответ ПаронджановаУважаемый ORG100H!
Если говорить точно, я не знаю. Этот вопрос я не исследовал, не думал над ним. Таким образом, на Ваш вопрос у меня нет ответа.
Впрочем, если позволите, я хотел бы добавить кое-какие соображения самого общего характера. Разобью свой комментарий на два пункта.
Пункт 1. ПРОЦЕДУРНЫЕ И ДЕКЛАРАТИВНЫЕ ЗНАНИЯ
Человеческие знания, выраженные с помощью любого письменного языка, можно разбить на две части: процедурные и декларативные.
Процедурные (алгоритмические, императивные, операторные, технологические) знания содержат сведения о последовательности информационных или физических действий, а также о выборе пути при разветвлении процессов. Примерами являются алгоритмы, компьютерные программы, а также любые технологические процессы (промышленные, сельскохозяйственные, медицинские и т. д.).
Декларативные (дескриптивные, атрибутивные, описательные) — это знания не о действиях, а об описаниях информационных и физических объектов. Примером является типичная запись в базе данных:
Фамилия; Имя; Отчество; Год рождения; Образование; Должность Иванов; Сергей; Петрович; 1980; высшее; менеджер
Для изложения декларативных знаний представители разных профессий нередко используют различные декларативные языки, в том числе графические. Например, декларативные знания конструктора выражаются на языке конструкторских чертежей, электрика — на языке электрических схем, географа — на языке географических карт.
МОЖНО ЛИ СОЗДАТЬ ЕДИНЫЙ ЯЗЫК ПРЕДСТАВЛЕНИЯ ПРОФЕССИОНАЛЬНЫХ ЗНАНИЙ?
Для наших целей большой интерес представляет вопрос: можно ли придумать единый универсальный язык, удобный для специалистов любой профессии и позволяющий улучшить взаимопонимание между ними?
Для декларативных знаний ответ, очевидно, будет отрицательным. Потому что нельзя скрестить ужа с ежом и придумать разумный и полезный гибрид электрической схемы и географической карты (или конструкторского чертежа). Такой путь неизбежно ведет в тупик.
Поэтому придется смириться с выводом, что специалисты разных профессий будут и впредь использовать множество самых разнообразных декларативных языков. Унификация здесь принципиально невозможна.
Но есть и хорошая новость. В отличие от декларативных знаний процедурные знания специалистов любого профиля имеют в точности одинаковую структуру. Эта структура нисколько не зависит от конкретной специальности и предметной области.
Отсюда проистекает важный вывод:
Для отображения любых процедурных знаний можно использовать один и тот же язык, общий для всех научных и учебных дисциплин, а также для управленческих решений и бизнес-процессов.ДАВАЙТЕ ОБСУДИМ РЕЗУЛЬТАТ
Полученный вывод очень важен по трем причинам.
Во-первых, создаются благоприятные предпосылки для построения универсального процедурного языка, позволяющего выражать любые процедурные знания в любой предметной области в ЕДИНОЙ СТАНДАРТНОЙ ФОРМЕ.
Во-вторых, универсальный (в самом широком смысле слова) процедурный язык мог бы сыграть роль межотраслевого и междисциплинарного языка, содействующего решению важнейшей проблемы, — проблемы взаимопонимания между учеными, специалистами, бизнесменами и специалистами по государственному управлению.
В-третьих, средства для описания структуры деятельности (которые также относятся к процедурным знаниям) играют особую роль в человеческой жизни. В самом деле, человек — деятельное существо. От рождения до смерти он непрерывно действует. Деятельность выражает сущность жизни. Бездеятельность — это смерть.
Поэтому знания о структуре деятельности и бизнес-процессов (процедурные знания) составляют важнейший компонент человеческих знаний, их основу. Можно предположить, что в системе человеческих знаний процедурные знания играют фундаментальную роль — роль несущей конструкции или каркаса, который скрепляет между собой (склеивает, цементирует) отдельные фрагменты декларативных знаний.
Сказанное хорошо согласуется с известным мнением, что
«большинство знаний об окружающем мире можно выразить в виде процедур или последовательности действий, направленных на достижение конкретных целей» [18].
НУЖДА В ЕДИНОМ ЯЗЫКЕ ОЧЕНЬ ВЕЛИКА
Социально-экономические успехи общества сильно зависят от разработки и внедрения новых технологий. Между тем способы описания структуры деятельности, бизнес-процесов и новых технологических процессов, используемые специалистами (в широком смысле слова), недостаточно формализованы и слабо используют опыт, накопленный в алгоритмизации и программировании.
С другой стороны, многие математики, алгоритмисты и программисты испытывают серьезные затруднения при необходимости наглядно и доходчиво описать сущность, структуру и содержание предлагаемых математических решений, алгоритмов и создаваемых программных комплексов и передать соответствующие знания другим людям.
В обоих случаях одна из причин этого негативного явления заключается в том, что сегодня нет подходящего формального языка. Языка, способного не только описать проблему и ее решение, но и обеспечить высокоэффективное интеллектуальное взаимопонимание и производственное взаимодействие между людьми. Это особенно важно при создании крупномасштабных проектов.
Нужда в таком языке весьма велика. Его отсутствие наносит заметный ущерб.
Изложенные соображения позволяют сделать два вывода:
• создание универсального процедурного языка является осуществимой задачей;
• искомый язык следует строить, в первую очередь, как язык формализации именно процедурных (а не декларативных) профессиональных знаний.
При этом проектирование и программирование на процедурных языках (псевдоязык, Бейсик, Паскаль, Си, язык ассемблера и т. д.) можно рассматривать как частный случай более общей проблемы — формализации процедурных знаний и описания структуры деятельности и бизнес-процессов.
ПОЧЕМУ НЕЛЬЗЯ ЖИТЬ ПО-СТАРОМУ?
Информационная технология — основа всех современных интенсивных наукоемких технологий. Результирующая производительность труда в наукоемких, оборонных и иных отраслях в огромной степени зависит от правильного выбора информационной технологии, от эффективного взаимодействия специалистов народного хозяйства между собой и с вычислительной техникой.
Сегодня эффективность невелика, что вызвано целой гаммой причин. В частности, сложностью современных языков, их фактической непригодностью для быстрого освоения, легкого понимания и удобной формализации профессиональных знаний. В особенности при решении трудноформализуемых, так называемых слабоструктурированных задач. Именно эта сложность явилась камнем преткновения, ахиллесовой пятой информатики.
Этот фундаментальный недостаток превратил формализацию профессиональных знаний и разработку сложных компьютерных программ в сверхтрудный интеллектуальный процесс, доступный сравнительно узкой социальной прослойке и недоступный всем остальным. На начальном этапе, пока компьютеров было немного, проблема не вызывала особых хлопот. Всегда можно было найти группу интеллектуалов, способных преодолеть любые сложности. Однако затем ситуация коренным образом изменилась. Вступление в эру всеобщей компьютеризации потребовало привлечения сотен тысяч и миллионов людей, интеллектуальные возможности которых существенно ниже, чем у элитных групп населения.
Драматическая недооценка чисто человеческих проблем (трудностей понимания) привела к плачевному результату. Сегодня выяснилось, что, несмотря на все усилия, значительная часть специалистов так и не научилась расшифровывать иероглифы нынешних заумных языков программирования. И, как следствие, оказалась отстраненной от плодотворного взаимодействия с программным обеспечением компьютеров. Это обстоятельство не позволяет им автоматически и эффективно обрабатывать собственные и чужие профессиональные знания.
Все это оказывает негативное влияние на интеллектуальный уровень общества, ощутимо снижает творческие возможности людей и эффективность организаций.
Пункт 2.Уважаемый ORG100H! Вернусь к Вашему вопросу: что можно предложить для двумерного представления структур данных?
Мне кажется, полезная (хотя и отчасти устаревшая) информация на этот счет содержится в следующих книгах:
1. Martin J., McClure C. Diagramming Technique for Analysts and Programmers. N. J.: Prentice Hall, Inc., 1985.
2. Martin J. Recommended Diagrammed Standards for Analysts and Programmers. N. J.: Prentice Hall, Inc., 1985.
3. Martin J. Rapid Application Development. N.-Y.: Macmillan Publishing Co., 1991.
Другим источником полезных сведений является современная литература по СASE-технологиям. К сожалению, это все, что я могу сказать.
Александр Ильин Четверг, 20 Март, 2008 21:27 …Даже захотелось написать ДРАКОН-редактор для Оберона…
Ответ ПаронджановаУважаемый Александр! Поддерживаю Вашу инициативу. Готов оказать всемерную помощь.
Илья Ермаков Четверг, 20 Март, 2008 22:25 А я позавчера получил заказанную книгу "Почему мудрец похож на обезьяну, или Парадоксальная энциклопедия современной мудрости". Книга очень интересная, советую другим. Прямо скажу, что из названия и краткой аннотации имел даже некоторое предубеждение. Однако оказалось наоборот, опасения не оправдались
Владимир Данилович, впечатления выскажу обязательно, частью тут - частью письмом! Но сначала дочитаю и осмыслю хорошенько + увяжу с некоторыми другими интересными вещами, с которыми разбирался недавно.
Ответ ПаронджановаУважаемый Илья! Благодарю. С огромным интересом выслушаю Ваше мнение.
Конец Части 5. Конец ответов Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования Дракон», представленные на 5-й странице форума.
Продолжение (Часть 6) последует примерно через 10 дней.
Вход
FAQ
Поиск
Смотрят-же ассемблерный код 
