Выше в сообщении от 24 февраля 2008 года (в Части 1) я привел фрагменты дискуссии о языке Дракон на сайте Натахаус. В этом сообщении изложена Часть 2, которая (в отличие от моего обещания) содержит ответы не на все замечания, прозвучавшие на форуме, а лишь на те, что изложены на
1-й странице форума. Затем (примерно через неделю) последует Часть 3 и т.д.
Причина изменения планов проста. Подготовка ответов потребовала значительно больше времени, чем я предполагал. Но я по-прежнему исполнен решимости обсудить все, что Вы посчитаете нужным. Приношу извинения за задержку с ответом.
С глубоким уважением Владимир Паронджанов
Часть 2. Ответы Паронджанова на вопросы и критические замечания участников форума «Визуальный язык программирования “Дракон”, представленные на 1-й странице форумаЗамечания обсуждаются в том порядке, в каком они появились на форуме.
Ярослав Романченко Четверг, 31 Май, 2007Ради интереса поискал историю названия "Графит-Флокс". Оказывается - ракетное топливо "Графит-ФлОкс" - Графит+Фтор+Кислород
Ответ ПаронджановаЭто неверно. ГРАФИТ расшифровывается так: ГРАФика И Текст.
ФЛОКС означает Формализованное Логическое Описание Крупных Систем.
Теперь по существу. Графит-Флокс — это технология (точнее CASE-технология) разработки алгоритмов и программ по методу «программирование без программистов». (Закавыченные слова нуждаются в оговорке, но для краткости я ее опускаю).
Графит — это графический процедурный язык реального времени, в котором есть особенность, а именно: в клеточках блок-схем Графита используются, так называемые флокс-идентификаторы (идентификаторы данных и объектов, написанные по специальным правилам). Но значение этих идентификаторов в языке Графит ПРЕДНАМЕРЕННО НЕ ОПРЕДЕЛЕНО.
А где оно определено? Значение флокс-идентификаторов задается с помощью специального языка — декларативного языка Флокс. Последний служит для описания данных, объектов и обязательных частично формализованных комментариев.
При этом используются два редактора:
• графит-редактор (для формального графического описания алгоритмов);
• флокс-редактор (для формального описания данных, объектов и обязательных формализованных комментариев).
Совокупность флокс-описаний вводится в реляционную базу данных ФЛОКС, которая затем преобразуется в реляционную базу объектов. База данных ФЛОКС обычно содержит около 3000 флокс-описаний (для разных ракет это число заметно варьирует). У каждой ракеты-носителя и у каждого разгонного блока свое наполнение базы данных ФЛОКС.
Заметьте: ГРАФИТ и ФЛОКС — это не два самостоятельных языка, а две половинки одного языка — языка ДРАКОН.
Удобство в том, что во многих случаях (хотя и не всегда) можно исправлять флокс-описания, не меняя графит-алгоритмы. И наоборот, вносить изменения в графит-алгоритмы, не трогая базу данных ФЛОКС.
Графит-алгоритмы и флокс-описания в нашем научно-производственном центре создают не программисты, а разработчики, которые понимают физику процесса. Документация на графит-алгоритмы и флокс-описания выпускается не по стандартам ЕСПД, а по стандартам ЕСКД (Единая система конструкторской документации). Она в обязательном порядке проходит нормализационный контроль (нормоконтроль) в отделе нормализации и стандартизации. И сдается в отдел технической документации.
Я ввел понятие «флокс-формуляр» и предложил ввести в систему конструкторской документации новый документ под таким же названием. Так и было сделано. Каждая лаборатория, разрабатывающая флокс-описания, выпускает свой флокс-формуляр, который имеет строго определенную форму, строго определенные разделы и прочую начинку. Совокупность флокс-формуляров описывает содержание базы данных ФЛОКС.
Повторю: флокс-формуляр — это обязательный официальный документ, который проходит нормоконтроль и сдается в отдел технической документации.
Графит-алгоритм — это тоже обязательный официальный документ, который проходит нормоконтроль и сдается в отдел технической документации. Все это делают не программисты, а разработчики приборов и комплексники.
Графит-алгоритмы и флокс-описания в электронном виде передаются в отдел программирования. Там производится автоматическая или полуавтоматическая трансляция в коды бортового компьютера «Бисер», разработанного в нашем центре. Слово Бисер происходит от слова БИС (Большие Интегральные Схемы). Управляющий компьютер Бисер является мозговым центром системы управления ракетой.
В сети встречается информация, что Графит-Флокс — это операционная система. Это неверно.
Конечно, у нас есть операционная система реального времени компьютера Бисер. Но она не имеет специального названия.
Илья Ермаков Четверг, 31 Май, 2007Штука очень интересная. Предлагаемая нотация действительно сильная и понятная.
Однако все же хочется поспорить с автором - Паронджановым. Все то же избитое утверждение, что "графическое представление информации понимабельнее, поэтому выбирать надо именно его, а текстовое представление программ неизбежно отомрет". При этом аргументация такова, что панорамным видением ("симультанный режим") человек может воспринимать информацию на порядок быстрее, нежели концентрированным ("сукцессивный режим"). Вроде бы не поспоришь, но лично я вижу тут два НО:
1) Все эти рассуждения базируются на тезисе "при возможности эквивалентного графического представления". А это предположение верно только для относительно простых систем. В сложных системах структура многомерна, и эквивалентно отобразить ее в плоский чертеж просто невозможно. Текстовый язык отображает эту структуру за счет символических связей между сущностями, именных ссылок, так сказать. Это позволяет хоть как-то воспринимать структуру системы в том или ином разрезе, формируя в уме многомерную семантическую сеть. Отобразить же многомерные связи графически - да повеситься можно... Электронщики-то неспроста уже давно ушли на текстовую нотацию - понять спецификацию на Verilog/VHDL - или что там у них - как-то получается, но разобраться в сгенерированной по спецификации топологии - специалисты говорят, что это практически невозможно.
2) Панорамное внимание на то и панорамное, что работает "по верхам", формируя общую, примерную картинку. А часто наоборот требуется искусственное замедление восприятия, фокусировка, и текстовое представление это дает, а графическое будет наоборот рассеивать, "замыливать" взгляд.
Ответ ПаронджановаУважаемый Илья!
Вы приписываете мне фразу «Графическое представление информации понимабельнее, поэтому выбирать надо именно его, а текстовое представление программ неизбежно отомрет».
По-моему, это неточная цитата. Мне кажется, я такого не говорил. Потому что без текста обойтись, разумеется, нельзя.
Вот точная цитата из моей книги (в ней сформулирован принцип эргономизации дионформации, который я считаю очень важным):
«…чтобы улучшить работу ума, необходимо улучшить когнитивное качество диоинформации, эргономизировать ее. При проектировании диосцен необходимо, в частности, заботиться о том, чтобы представить заданное смысловое содержание с помощью оптимального сочетания эргономичного текста, эргономичных формул и эргономичных изображений (статичных и динамических)» (стр. 326).
Далее Вы пишете: «Электронщики-то неспроста уже давно ушли на текстовую нотацию - понять спецификацию на Verilog/VHDL - или что там у них - как-то получается, но разобраться в сгенерированной по спецификации топологии - специалисты говорят, что это практически невозможно.
Уважаемый Илья! Большую часть своей жизни я проработал инженером — разработчиком вычислительных устройств. В период создания орбитального корабля «Буран» я был начальником лаборатории комплексной разработки вычислительной системы Бурана. Так что об этих делах знаю не понаслышке.
Вы правильно говорите, что разобраться в сгенерированной по спецификации топологии крайне трудно. Ваше высказывание аналогично такому: разобраться в сложной программе по двоичной распечатке машинного кода крайне трудно.
Но Ваше утверждение, что «Электронщики… уже давно ушли на текстовую нотацию» является в корне ошибочным. С равным успехом Вы могли бы сказать «Географы уже давно отказались от географических карт и принялись описывать их словами». «Конструкторы уже давно отказались от конструкторских чертежей» и т.д.
Смею Вас заверить: при разработке электрических (логических) схем, временных диаграмм (циклограмм) и других (важных для мыслительного процесса разработки) документов электронщики никогда не переходили на текстовую нотацию! И никогда не перейдут! Приведенный Вами пример справедлив, НО СОВЕРШЕННО НЕ ТИПИЧЕН.
Но даже в Вашем примере дело обстоит несколько иначе. Ведь первым шагом к созданию нового комплекса приборов является разработка общих и структурных схем, электрических схем и временных диаграмм. И только после этого можно приступать к разработке (или автоматической генерации) конструкторских чертежей и монтажных схем (схем соединений), о которых Вы пишете.
Но откуда берется автоматически сгенерированная топология (разводка проводников на печатной плате или в кристалле интегральной схемы)? Что является ее первоисточником? Ответ прост: электрическая (логическая) схема! То есть графика!
В моей книге на стр. 52—53 Вы найдете цитату из Джеймса Мартина:
В 1989 г. журнал “Форчун” попытался выяснить, почему так трудно писать программы: «Программное обеспечение — это “материя чистой мысли”, бестелесная и умозрительная; поэтому проектировщики не в состоянии нарисовать ясные, точные и подробные чертежи и схемы, как это делают разработчики электронных приборов, чтобы дать четкие указания программистам, что нужно сделать. Следовательно, повседневное общение между программистами, их начальниками и обычными людьми, которые используют программы, — это вещь в себе». Однако сторонники RAD думают по-другому. Комментируя указанную статью, Джеймс Мартин пишет: «Важно понять, что эта народная мудрость сегодня уже неверна». В рамках RAD применяются «точные и детальные чертежи и схемы (аналогичные тем, что рисуют конструкторы электронного оборудования) с помощью технологии I-CASE, причем из этих чертежей генерируется программный код. На уровне чертежей выполняется значительная часть проверок. Эти чертежи и схемы весьма эффективны при повседневном общении программистов, системных аналитиков, менеджеров и конечных пользователей. Попытка создавать программы без этих средств означает только одно — безответственное руководство» [16].
Откуда взята эта цитата? Из хорошо известной Вам книги «Martin J. Rapid Application Development. N.-Y.: Macmillan Publishing Co., 1991». Это руководство по методологии RAD (Rapid Application Development), в котором больше 800 страниц. Сегодня эта книга частично устарела, но мудрая мысль о том, что ПРОГРАММИСТАМ НУЖНО ВСЛЕД ЗА ИНЖЕНЕРАМИ НАУЧИТЬСЯ ДЕЛАТЬ ХОРОШИЕ ЧЕРТЕЖИ, на мой взгляд, полностью сохраняет силу.
Илья! В Вашем сообщении есть и другие пункты, с которыми я не могу согласиться. Но мой ответ и так чрезмерно затянулся. Если хотите, можно подробно обсудить все интересующие Вас детали по телефону или при личной встрече. Будете в Москве — заходите в гости. Я живу в Новых Черемушках. Мой телефон 331-50-72. Звоните, я буду рад.
Илья Ермаков Среда, 18 Июль, 2007 23:42«…исходной идеей для Дракона послужили работы Дейкстры, который выработал концепцию структурного программирования…»
Ответ ПаронджановаУважаемый Илья!
Мой комментарий будет не совсем обычным. На это есть две причины.
Причина 1. Знаю, что Вы интересуетесь работами Дейкстры. Видел Вашу подборку его статей на этом сайте.
http://oberoncore.ru/index.php?Itemid=2 ... &task=view
Поэтому мне хочется считать Вас экспертом по Дейкстре. И обсудить с Вами кое-какие бредовые идеи.
Причина 2. Читая Ваши сообщения на этом и других сайтах, я обратил внимание, что Вы, во-первых, делаете акцент на эргономичности языка Дракон (хотя и с оговорками) и, во-вторых, отмечаете, что графический синтаксис этого языка является строгим формализмом. Но в чем математическая суть этого формализма? Мне показалось, что на последний вопрос Вы обратили недостаточное внимание.
Начну с математики. Говоря о математических основах графики Дракона, выскажу 10 замечаний.
Замечание 1. Математическая суть графики Дракона не очень проста. Но! Эта сложность спрятана на дне глубокого колодца и полностью скрыта от программистов и пользователей, которые создают программы на языке Дракон. Им кажется, что никакой сложности нет и в помине. Что все очень легко и просто. Они могут ничего не знать об этой математике. Больше того, им вовсе не надо ее знать. Где же спрятана эта математика? Она спрятана во внутренних алгоритмах графического дракон-редактора (дракон-конструктора). Самое интересное в том, что разработчики дракон-редактора тоже могут ее не знать. Знание математических основ настолько глубоко спрятано, что никто не обязан их изучать. Как будто их и вовсе нет. Но они (математические основы), конечно, есть.
Замечание 2. Илья! Первая возможная трактовка конструкции «силуэт» Вам хорошо известна, поскольку Вы пишете: «это детерминированный конечный автомат! В каждом состоянии выполняется некая ветка алгоритма, по окончании которой происходит переход в какое-либо другое состояние… Это особенно интересно — прямая поддержка автоматного программирования».
Я тоже об этом упоминаю (см. сноску на стр. 260 и рис. 137).
Замечание 3. Но существует и несколько иная трактовка, связанная с методом (теоремой) Ашкрофта-Манны. Этот метод позволяет преобразовать неструктурную программу в структурную путем введения переменной состояния (см. Йодан Э. Структурное проектирование и конструирование программ. М.: Мир, 1979. С. 192—196, а также Котов В.Е., Сабельфельд В.К. Теория схем программ. М.: Наука, 1991. С. 233—238).
Замечание 4. Опираясь на идею Ашкрофта-Манны и теорему структуризации, я сформулировал две теоремы:
Теорема 1. Любая структурная программа может быть изображена на языке ДРАКОН двумя способами: в виде примитива и в виде силуэта.
Теорема 2. Произвольная (неструктурная) программа в ряде случаев не может быть изображена в виде примитива; однако с помощью эквивалентных преобразований, допускающих введение дополнительных переменных (идентификаторов ветки), она всегда может быть изображена в виде силуэта (см. мою книгу, стр.100).
Замечание 5. В замечаниях 1—4 речь шла об узком вопросе — математике конструкций «силуэт» и «ветка». В замечаниях 6—10 речь пойдет о более широком взгляде на проблему — о математических основах всего графического синтаксиса.
Замечание 6. Эта более широкая математика может показаться еще более сложной, так как она подразумевает почти полный отказ от традиционного понятийного аппарата и замену его на принципиально новый и непривычный понятийный аппарат. Чтобы математически обосновать графический формализм языка Дракон, я разработал два новых теоретических подхода:
• графическое структурное программирование (которое коренным образом отличается от текстового структурного кодирования — см. главу 16);
• графическое логическое исчисление (исчисление икон) — см. главу 17.
Замечание 7. Однако ничего страшного нет. Эта математика также спрятана на дне глубокого колодца. Она полностью скрыта от программистов и пользователей, которые создают программы на языке Дракон. Им кажется, что никакой сложности нет и в помине. Что все легко и просто. Они могут ничего не знать об этой математике. Больше того, им вовсе не надо ее знать. И так далее (см. Замечание 1).
Замечание 8. На основе указанных новых теоретических походов разработано формальное описание графического синтаксиса языка Дракон (см. главу 15).
Замечание 9. Надо ли знать формальное описание графического синтаксиса программистам и пользователям, которые пишут программы на Драконе? Нет, не надо. Потому что это описание «зашито» во внутренних алгоритмах дракон-редактора. Они должны знать только инструкцию по использованию дракон-редактора. Чтобы ее освоить, сидя за компьютером, надо потратить примерно час-полтора.
Замечание 10. Однако это описание (формальное описание графического синтаксиса) должны хорошо знать разработчики дракон-редактора. Подробная инструкция по разработке такого редактора изложена в главе 14.
Илья! На этом я заканчиваю обсуждение математики Дракона, на которую хотел обратить Ваше внимание.
Перехожу ко второй теме — изложению моей бредовой идеи.
В книге я постеснялся ее высказать. Есть тема, которая изложена в книге плохо — робко, обтекаемо, без острой постановки вопроса и почти без критики в адрес Эдсгера Дейкстры. Сейчас я хочу нарочито заострить вопрос и посоветоваться с Вами и Вашими коллегами как с профессионалами высокого класса. Так сказать, вынести бредовую идею на обсуждение и выслушать Вашу критику. Если критика будет убийственной, придется забить осиновый кол в ее могилу. Если нет, я опубликую ее при переиздании книги.
Эдсгер Вибе Дейкстра (1930—2002), несомненно, великий человек. Ему надо поставить золотой памятник. Однако у великих людей могут быть и великие ошибки. В данном случае речь пойдет не об ошибке, а об упущении. О серьезном математическом упущении, которое, как мне кажется, неблагоприятно отразилось на мировой практике программирования.
В чем суть? Как известно, Дейкстра ввел три конструкции: сочленение, выбор, повторение. Он пишет (цитирую по русскому переводу):
«Итак, мы познакомились с тремя типами разложения; можно называть их соответственно “сочленение”, “выбор”, “повторение”. Для понимания первых двух служит рассуждение с перечислением, а для последнего нужна математическая индукция».
«Программы, при написании которых управление последовательностью действий осуществляется только при помощи выбора и повторения, допускают непосредственный перевод на некий язык программирования, который отличается от исходного только тем, что все управление последовательностью действий должно быть выражено передачами управления на метки. Однако обратное утверждение было бы неправильным. Напротив, если мы ограничимся указанными тремя типами разложения, то это приведет к ограничению топологии блок-схем по сравнению с различными блок-схемами, которые могут быть получены, если разрешить проведение стрелок из любого блока в любой другой блок. Отказавшись от большого разнообразия блок-схем и ограничившись данными тремя типами операторов управления, мы следуем тем самым некоей последовательностной дисциплине».
«Почему я предлагаю придерживаться этой последовательностной дисциплины? Это решение может быть обосновано различными способами, и я попытаюсь изложить несколько таких обоснований в надежде на то, что хотя бы одно из них удовлетворит моих читателей». См. Э. Дейкстра. Заметки по структурному программированию. В кн.: У.Дал, Э. Дейкстра, Ч. Хоор. Структурное программирование. М.: Мир, 1975. С. 28.
В чем состоит моя «бредовая» критика в адрес Дейкстры?
Я полагаю, что Дейкстра либо не был знаком с математической логикой в должной мере, либо не сумел применить ее к приведенным выше рассуждениям. К чему это привело?
Дейкстра выделяет три понятия: сочленение, выбор и повторение. Он называет их ОПЕРАТОРАМИ управления. С точки зрения математики, здесь все правильно. Но аляповато.
Пример 1. Если посмотреть на программу, никто не увидит оператор сочленения. Операторы выбора есть, операторы повторения (циклы) есть, а оператора сочленения нет. Нет, и все тут! Конечно, само сочленение есть: оно состоит в том, что команды пишутся подряд. Но ОПЕРАТОРА сочленения нет — корова языком слизала. Выходит, что некоторые операции из выделенной Дейкстрой тройки понятий имеют операторы и ключевые слова, а другие нет. Это некрасиво (а если отбросит деликатность — коряво).
Пример 2. А где оператор вложения? Ведь само вложение есть (например, «цикл в цикле». А оператора вложения нет. Неувязочка получается.
Этот недостаток можно легко устранить, если изменить общий взгляд на процедурное программирование. Если во главу угла поставить не три управляющие конструкции Дейкстры, а одну единственную операцию — вложение. Причем операцию вложения следует рассматривать сквозь призму математической логики. Как логический вывод.
В языке Дракон именно так и сделано (см. главы 14—17). В рамках философии Дракона ключевые слова управляющих конструкций становятся ненужными. Они рассматриваются как устаревшие, лишние и даже вредные (см. стр. 259—266). В самом деле, глядя на дракон-схему, нельзя обнаружить эти ключевые слова даже под микроскопом. Почему? Потому что в языке Дракон используется совершенно другой понятийный аппарат (см. стр. 259—266).
Дракон — это не просто новый язык (новое семейство языков). Это новый взгляд на процедурное программирование. Если угодно — новое мировоззрение.
Конечно, можно попытаться к новой идее (графическому программированию) применить старый понятийный аппарат, взятый из текстового программирования. Но это не очень хорошо. Потому что старый понятийный аппарат будет затруднять понимание сущности проблемы и тормозить использование вновь открывающихся возможностей.
Смена понятийного аппарата — это переход к новому пониманию глубинной сущности вещей, то есть к новому мировоззрению в области процедурного программирования.
Вернусь к «бредовой» идее. Суть ее такова.
Дейкстрианская революция состоит в том, что Дейкстра ввел строгую дисциплину в анархическом царстве процедурного программирования. Но любая дисциплина — это ограничение свободы. Недостаток в том, что Дейкстра ввел неоправданно жесткие ограничения. Фактически Дейкстра добился успеха за счет того, что ввел интеллектуальное рабство и заковал программистов в кандалы.
Первые голоса протеста прозвучали в самом начале его мощной атаки против засилья анархистов. Оппоненты доказывали, что хлесткий лозунг Дейкстры «GOTO considered harmful» в ряде случаев не верен. Со временем им удалось заметно облегчить тюремный режим и сделать кандалы более легкими. Они действовали методом троянского коня, используя приемы, которые я называю «заменителями goto» (см. стр. 246—253 моей книги).
Но тюрьма осталась тюрьмой. И железными решетками на ее окнах являются так называемые «структурные управляющие конструкции». Когда-то они сыграли позитивную роль и помогли победить анархистов (как иногда говорят, превратить программирование из шаманства в науку).
Сегодня тюрьма имени Эдсгера Дейкстры тормозит повышение производительности труда программистов. И делает разработку алгоритмов и программ по методу «программирование без программистов» крайне трудной или даже недоступной для большинства специалистов, не знающих программирования.
Лозунг академика Андрея Ершова «Программирование — вторая грамотность!» оказался утопическим. Потому что Дейкстра построил удивительно прочную тюрьму, в которой почти все запрещено. Куда ни повернись — все нельзя!
Задача состоит в том, чтобы спилить решетки на окнах тюрьмы, резко уменьшить число запретов и ограничений, то есть предоставить узникам свободу.
Эту задачу и решает язык Дракон. Он разрушает тюрьму имени Эдсгера Дейкстры. И позволяет совершить прыжок из царства необходимости в царство свободы.
Каким образом? Благодаря замене текстового структурного программирования на графическое структурное программирование. Последнее, разумеется, также является дисциплиной. Но в ней большинство запретов снимается. То, что раньше было нельзя, теперь можно.
Многие запреты Дейкстры противоречат здравому смыслу и затрудняют понимание алгоритмов и программ. Пример приведен на рис. 26б.
Дейкстра запретил подобные алгоритмы, объявив их неструктурными. Но такие алгоритмы часто встречаются в практическом производстве. Примерно так выглядит, например, контрольный набор стартовых готовностей.
Конструкция на рис. 26б не считается «структурной управляющей конструкцией». Поэтому она запрещена. Что отсюда следует? Мой ответ таков: пусть структурные управляющие конструкции отправляются на заслуженную пенсию. Потому что во многих случаях (хотя и не всегда) они уродуют нормальный ход человеческой мысли.
Недопустимо запрещать правильный процесс мышления. Его надо разрешить. И Дракон разрешает.
Сегодня следует поблагодарить великого нидерландского ученого за его фундаментальный вклад в развитие программирования. И поставить почетный караул у его памятника. Но надо также осознать, что в современных условиях структурные управляющие конструкции — устаревшее и вредное понятие.
Info21 Четверг, 19 Июль, 2007Насчет замены языка графикой — чушь. Просто чушь. Человечество бы руками махало вместо разговора, и рисовало вместо письма. Язык — самый мощный передатчик информации.
Ответ ПаронджановаУважаемый Info21!
Я люблю острую критику. Так что Ваша реплика мне глубоко симпатична. Но ответить на Вашу критику сложно, так как я плохо понял Вашу мысль.
Мне кажется, что язык жестов («размахивание руками») и звуковой язык («разговор») не имеют отношения к теме, так как предметом обсуждения является, in my humble opinion, только письменный (а не жестовый и не звуковой) язык.
Но главную загадку для меня представляет Ваш лозунг «Язык — самый мощный передатчик информации». Что он означает? Об этом я могу только гадать.
Чтобы Вы не подумали, что я пытаюсь трусливо уклониться от Вашего сокрушительного нокаутирующего удара, поднимаю брошенную Вами перчатку и начну гадать.
Ниже я приведу три варианта своего гадания (то есть дам три варианта ответа на Вашу критику). Вполне возможно, что в процессе гадания я попаду пальцем в небо и не отвечу на поставленный Вами вопрос. В таком случае поправьте меня.
Гадание первое (первый вариант моего ответа на критику Info21).
О каком языке идет речь? Может быть, Вы имеете в виду естественный язык?
Если да, то я считаю тезис «Естественный язык — самый мощный передатчик информации» глубоко ошибочным. Впрочем, у Вас есть влиятельный союзник — знаменитый французский лингвист Андре Мартине (1908—1999). Вот его коронная фраза: «Язык — это способность сказать все».
В чем здесь ошибка? В том, что естественный язык принципиально не позволяет «сказать все». Он (естественный язык) годится для решения только самых простых жизненных задач. Для сложных задач он решительно не подходит. Цивилизация достигла нынешнего блеска благодаря тому, что слабосильный естественный язык был дополнен надежными костылями могущественных искусственных языков.
Сошлюсь на мнение ученых. Знаменитый математик Николай Лобачевский, выступая на торжественном собрании Казанского Императорского университета 5 июля 1828 года в первую годовщину его пребывания на посту ректора, сказал:
«Чему… одолжены своими блистательными успехами… науки, слава нынешних веков, торжество ума человеческого? Без сомнения, искусственному языку своему».
Кстати сказать, речь Лобачевского очень любопытна. Захотите почитать, вот ссылка:
http://www.ksu.ru/infres/nikolaev/kniga/gl1.htm Гадание второе (второй вариант моего ответа на критику Info21).
Может быть, Вы имеете в виду, что язык — это широкое понятие, которое охватывает не только естественный язык, но и полную совокупность искусственных языков, включая язык математики, логико-математические исчисления, языки программирования и т.д.? Но тогда почему Вы исключаете из этого широкого понятия графические искусственные языки?
Может быть, Вы считаете, что графические языки не существуют?
Но это не так. Они существуют. И в большом количестве.
В.Н. Агафонов сообщает: «…языки делятся на два основных класса: графические и текстовые». См. Агафонов В.Н. Языки и средства спецификаций программ. В кн.: Требования и спецификации в разработке программ. Перевод с английского под ред. В.Н. Агафонова. М.: Мир, 1984. С. 292.
Возможно, Вы скажете, что это древняя и устаревшая книга.
Тогда наберите в Гугле запрос «Графический язык программирования». Вы получите море ответов. Возможно, Вы возразите: многие ответы не соответствуют теме. Это правда. Но некоторые соответствуют.
Гадание третье (третий вариант моего ответа на критику Info21).
Может быть, Вы считаете, что термин «графика» подразумевает строгий запрет на использование текста? Но почему? Даже в конструкторских чертежах используются текстовые символы. Графика без текста не бывает. Вернее, бывает, например, на картинах художников. Но ведь мы сейчас дискутируем не о произведениях искусства.
Я утверждаю: термин «графика», используемый в научно-технической сфере, очень часто или даже преимущественно обозначает совместное использование графики и текста. Возможно, Вы возразите: дескать, в программировании так не говорят. Это тоже неверно. Вот Вам пример — статья Владимира Зюбина (
zyubin@iae.nsk.su) — старшего научного сотрудника Института автоматики и электрометрии Сибирского отделения РАН (Новосибирск).
Статья называется: «Графика или текст: какой язык нужен программисту?». Вот ссылка
http://www.osp.ru/os/2004/01/183824/Уважаемый Info21! Вполне вероятно, что Вы со мной не согласитесь. В этих условиях единственное, что могу сделать — это рекомендовать Вам мою книгу «Паронджанов В.Д. Почему мудрец похож на обезьяну, или Парадоксальная энциклопедия современной мудрости». М.: РИПОЛ классик, 2007.
В этой книге я, в частности, очень подробно говорю о достоинствах и преимуществах эргономичной графики и привожу множество примеров. Кроме того, очень подробно доказываю, что широко распространенная вера в то, что естественный язык — самый мощный передатчик информации, является трагическим заблуждением, которое наносит человечеству огромный урон.
С большим уважением к Вашей позиции
Не согласный с Вами Владимир Паронджанов