В предисловии к первому изданию замечательной книги "Структура и Интерпретация Компьютерных Программ" (SICP) авторов Харольда Абельсона и Джеральда Джей Сассмана, есть цитата из статьи Марвина Минский "Почему программирование - хороший способ выражения малопонятных и туманно сформулированных идей." Цитата короткая, а полная публикация на русском языке мне не попадалась.
Ниже вы можете ознакомится с переводом этой статьи, и хотя написана она довольно давно, всё равно интересно ознакомится с мыслями такого человека как Марвин Минский, оригинальную статью можно найти здесь.
Данная статья представляет собой слегка отредактированную версию главы, опубликованной в книге "Дизайн и планирование II - Компьютеры в дизайне и коммуникации" (Design and Planning II - Computers in Design and Communication, (Martin Krampen and Peter Seitz, eds.), Visual Committee Books, Hastings House Publishers, New York, 1967.)
Существует общепринятое и распространенное мнение, что компьютеры могут делать только то, на что их запрограммировали. Это ложное суждение основано на путанице, существующей между формой и содержанием. Строгая грамматика не означает строгого описания процесса. Программист должен быть очень точен, следуя правилам компьютерной грамматики, однако содержание, которое он хочет выразить при помощи этих правил, остается свободным и ничем не ограничивается. И строгость грамматики обусловлена не компьютером, а программистом, который ее использует. Программисту даже не надо быть очень точным в формулировании собственных идей: у него в уме может быть определенный диапазон допустимых компьютерных ответов, при этом достаточно, чтобы компьютерные ответы не выходили за рамки этого диапазона. Программисту не надо ограничивать компьютер конкретными процессами. Под грузом сомнений он может попросить компьютер сгенерировать новые процессы, либо может предложить определенные правила выбора и "посоветовать" компьютеру, какой именно выбор сделать. Таким образом, компьютеры не надо программировать, слишком четко и ясно формулируя, что именно нужно выполнить и как именно это надо сделать.
Приведенное здесь рассуждение - не столько о "дизайне", сколько о том, чем вообще компьютеры могут нам помочь в нашей работе. По ряду причин обычно люди недооценивают эти возможности. Для начала я бы хотел предупредить об одной ошибке: не стоит, подобно многим, кто считает, что он полностью понимает ситуацию, занимать "умеренную" позицию. Фантасты, ученые всех мастей, экономисты-аналитики, психологи и даже логики часто твердят, пытаясь убедить всех, что компьютеры никогда не смогут по-настоящему думать. "Не стоит считать, что машины смогут думать, подобно людям: они могут делать только то, что в них заложено программой, они не могут быть оригинальными и творческими". Мы все уже слышали нечто подобное и большинство из нас согласно с такой точкой зрения.
Легко понять, почему ученые-гуманитарии любят разглагольствовать о малопонятной природе процесса мышления, поскольку из этого легко сделать ложный вывод о связи такой неясности с уникальной природой человеческого мышления. Но здесь важен не сам вывод. Вся ошибочность этой дискуссии состоит в широко распространенном убеждении, что невозможно написать компьютерную программу, которая бы делала нечто, выходящее за рамки очень четко поставленной задачи, четкой формулировки того, что должно быть сделано, и того, как это должно быть сделано. Это убеждение широко пропагандируется как учеными (и даже "компьютерщиками") так и гуманитариями.
Все, что нам говорят об ограниченности компьютеров, обычно принимает такие общие формы: "Компьютер творить не может. Он может делать только то, что ему сказали. Если процесс не сформулирован очень точно, компьютер его выполнить не сможет". В некотором смысле это правильно, в другом - абсолютно ложно. Прежде, чем пояснить, почему, интересно отметить, что задолго до появления компьютеров то же самое говорили о Дьяволе: он - единственный, кто мог быть творцом.
В сентябре 1966 года номере журнала Scientific American я обсудил три программы: программу Артура Самуэля для игры в шашки на уровне мастера; программу Томаса Эванса ANALOGY, которая позволяла на довольно хорошем уровне решать задачи оценки интеллекта при помощи распознавания аналогий между геометрическими фигурами, и программу Д. Борборва STUDENT для решения алгебраических задач старших классов выраженных неформальным языком:
Мэри вдвое старше, чем была Анна, когда Мэри было столько лет, сколько Анне сейчас. Если сейчас Мэри 24 года, сколько лет Анне?
эта программа решает некоторые задачи, но далеко не все. В той статье я поставил задачу идти дальше, продолжать работу в направлении более разностороннего интеллектуального развития. Однако, для моих целей даже в их сегодняшнем состоянии эти программы могут служить отличным примером: хотя они работают и с крайне ограниченным кругом задач, они уже достаточно делают, чтобы разрушить этот старый удобный для всех миф.
Старая точка зрения гласит, что программа - это "всего лишь" набор строгих правил, четко указывающих, что делать в каждой конкретной ситуации. Это - действительно полезная точка зрения для того, чтобы убедить новичков в программировании или для анализа программ, написанных новичками. Однако, для более сложных процессов (хотя в некотором смысле это "абсолютно" верно) также будет правильно сказать, что "дома - это всего лишь конструкции из строительных материалов" или "книги - это всего лишь длинные цепи слов". И правда: в обзоре моей статьи в Scientific American, сделанный в журнале Computer Reviews 8, 1, январь 1967 г., утверждается, что эти программы состоят из "поиска по словарю, последовательности функций поиска и сравнения, а также операций сортировки и объединения".
ЛОГИКА И СИСТЕМНОСТЬ
Давайте начнем с обсуждения одного утверждения, основанного на мнениях хороших логиков и философов. Нам говорят, что некоторые теоремы для доказательства последовательных логических систем имеют следствие: "Невозможно полностью механизировать процесс открытия, поэтому люди всегда будут иметь преимущество перед машинами". Я уверен, что практически каждый читатель слышал о теореме Гёделя. Большинство также слышало о предполагаемом выводе. Но это - не логический вывод, поскольку он основан на небрежных технических наблюдениях. Если она вообще применима к решению задач, теорема Гёделя применима исключительно к непротиворечивым логическим системам. Люди не столь непротиворечивы, поэтому нет причин, чтобы мы чувствовали какое-то стеснение и ограничивались созданием машин по таким принципам. Вместо этого мы можем создать машины, которые могли бы допускать противоречие фактических суждений, что уже и делается. Для этого нужно добавить набор правил для решения противоречий, шкалу приоритетов для выбора из противоречивых суждений и т.п. Простой пример такой схемы описан в докторской диссертации Бертрама Рафаэля, которую он защищал в Массачусетском технологическом институте в 1964 году. Приведем пример диалога с такой программой:
КАЖДЫЙ МАЛЬЧИК - ЧЕЛОВЕК (Я ПОНИМАЮ) ПАЛЕЦ - ЧАСТЬ РУКИ (Я ПОНИМАЮ) У КАЖДОГО ЧЕЛОВЕКА ДВЕ РУКИ (ЭТО ПРЕДЛОЖЕНИЕ ДВУСМЫСЛЕННО. ПЕРЕФРАЗИРУЙТЕ ЕГО) ЕСТЬ ДВЕ РУКИ У КАЖДОГО ЧЕЛОВЕКА (Я ПОНИМАЮ) СКОЛЬКО ПАЛЬЦЕВ У ДЖОНА? (Я НЕ ЗНАЮ, ЯВЛЯЕТСЯ ЛИ ПАЛЕЦ ЧАСТЬЮ ДЖОНА) ДЖОН - МАЛЬЧИК (Я ПОНИМАЮ) СКОЛЬКО ПАЛЬЦЕВ У ДЖОНА? (СКОЛЬКО ПАЛЬЦЕВ НА РУКЕ) НА КАЖДОЙ РУКЕ 5 ПАЛЬЦЕВ (Я ПОНИМАЮ) СКОЛЬКО ПАЛЬЦЕВ У ДЖОНА? (ОТВЕТ - 10) СКОЛЬКО МАШИН У ДЖОНА? (ЭТО ПРЕДЛОЖЕНИЕ ДВУСМЫСЛЕННО. ПЕРЕФРАЗИРУЙТЕ ЕГО) КТО ПРЕЗИДЕНТ США? (ФОРМА СУЖДЕНИЯ НЕ ОПОЗНАНА) МАЛЬЧИК ТОЛЬКО ЧТО ВЫШЕЛ ИЗ-ЗА СТОЛА (G02840 - СТОЛ) (Я ПОНИМАЮ) ЛАМПА - СЛЕВА ОТ СТОЛА (G02841 - ЛАМПА) (ВЫШЕУКАЗАННОЕ СУЖДЕНИЕ НЕВОЗМОЖНО) СТОЛ - СПРАВА ОТ СТУЛА (G02842 - СТУЛ) (Я ПОНИМАЮ) КАКОВО ОТНОСИТЕЛЬНОЕ ПОЛОЖЕНИЕ ЧЕЛОВЕКА? (ПОРЯДОК СЛЕВА НАПРАВО ТАКОЙ) (СТУЛ - МАЛЬЧИК - СТОЛ)
Система сбора знаний и ответов на вопросы Рафаэля показывает, как отдельным фактам дается высший приоритет, если они конфликтуют с общими принципами. Разумеется, подобный "принцип исключения" - очень упрощенный способ решения противоречий, который может использоваться исключительно в случаях, когда существует четкая разница между суждениями по уровню общности. Если они находятся на одном уровне, программа просто отклоняет более позднее суждение, как можно видеть на этом примере:
НА КАЖДОЙ РУКЕ ПО 5 ПАЛЬЦЕВ (Я ПОНИМАЮ) У ЧЕЛОВЕКА ДВЕ РУКИ (Я ПОНИМАЮ) МАЛЬЧИК - ЧЕЛОВЕК (Я ПОНИМАЮ) ТОМ - МАЛЬЧИК (Я ПОНИМАЮ) ДИК - МАЛЬЧИК (Я ПОНИМАЮ) ГАРРИ - МАЛЬЧИК (Я ПОНИМАЮ) ТОМ ИМЕЕТ ДЕВЯТЬ ПАЛЬЦЕВ (ДАННОЕ СУЖДЕНИЕ ДВУСМЫСЛЕННО, НО Я ПРЕДПОЛАГАЮ (ИМЕЕТ) ОЗНАЧАЕТ (ИМЕЕТ КАК ЧАСТЬ)) (Я ПОНИМАЮ) ДИК ИМЕЕТ ОДНУ РУКУ (ДАННОЕ СУЖДЕНИЕ ДВУСМЫСЛЕННО, НО Я ПРЕДПОЛАГАЮ (ИМЕЕТ) ОЗНАЧАЕТ (ИМЕЕТ КАК ЧАСТЬ)) (Я ПОНИМАЮ) СКОЛЬКО ПАЛЬЦЕВ У ТОМА? (ОТВЕТ - 9) СКОЛЬКО ПАЛЬЦЕВ У ДИКА? (ОТВЕТ - 5) СКОЛЬКО ПАЛЬЦЕВ У ГАРРИ? (ОТВЕТ - 10) СКОЛЬКО ПАЛЬЦЕВ У ДЖО? (Я НЕ ЗНАЮ, ЯВЛЯЕТСЯ ЛИ ПАЛЕЦ ЧАСТЬЮ ДЖО)
Разумеется, Рафаэль мог бы написать и другое правило назначения приоритетов. Кстати, суждение в программе "Это предложение двусмысленно…" относится к возможности, что слово "имеет" может означать либо "имеет как часть" или "владеет". Программа Рафаэля обычно делает верные предположения по изучению объектов, о которых уже известно, что они владеют определенными вещами либо являются частью определенных вещей и т.п. Далее я опишу это более подробно. Рафаэль наглядно показал, что такие "контекстуальные" решения можно запрограммировать, проиллюстрировав более общую идею или, скорее, показав другой и более здравый взгляд на программы вместо ранее существовавшего подхода "всего лишь". Поэтому мы попытаемся объяснить некоторые из лучших способов рассуждения о программах.
(1) ПРОГРАММА КАК ПОСЛЕДОВАТЕЛЬНОСТЬ ИНСТРУКЦИЙ, КОТОРЫЕ НАДО СОБЛЮДАТЬ.
Наиболее распространенная и простая точка зрения: компьютерная программа - последовательность четких операций, которые выполняются на основании определенных данных. Возьмем простой пример программы: предположим, что Х - число, данное как информация для ввода:
START: SET R = 1
LOOP: SET S = X/R
SET T=R+S
SET R = T/2
SET U = R x R
SET V = X - U
IF /V/ > .001, GO TO LOOP
ELSE PRINT VДанная программа, приписываемая Исааку Ньютону, рассчитывает приблизительное значение корня квадратного от Х. В каждой строке программы абсолютно ясно, каково текущее положение дел и что идет дальше. Разумеется, нужен математический анализ, чтобы доказать, что последовательность таких ситуаций вскоре приведет к допустимому значению R и окончанию всех вычислений. Поэтому никакого вреда не будет, если считать данные суждения последовательностью шагов. Команду "ПЕРЕЙТИ К" ("GO TO") можно считать очень коротким вариантом нескольких копий "основного цикла" ("main loop"). Разумеется, пока анализ не завершен, программу можно считать выражением полезной, но маловразумительной идеи.
(2) ПРОГРАММА КАК СУД
В программе Рафаэля нужно решить, означает ли слово "имеет" "владеет" или "имеет как часть", если речь идет о суждении в форме "х имеет у":
ДЖОН - ЧЕЛОВЕК (Я ПОНИМАЮ) ДИК - ЧЕЛОВЕК (Я ПОНИМАЮ) ЦЕПЬ - ЧАСТЬ ВЕЛОСИПЕДА (Я ПОНИМАЮ) БЕНЗОПИЛА ИМЕЕТ ЦЕПЬ (ДАННОЕ СУЖДЕНИЕ ДВУСМЫСЛЕННО, НО Я ПРЕДПОЛАГАЮ (ИМЕЕТ) ОЗНАЧАЕТ (ИМЕЕТ КАК ЧАСТЬ)) (Я ПОНИМАЮ) У ДЖОНА ЕСТЬ ЦЕПЬ (Я ПОНИМАЮ) ДИК ИМЕЕТ СТУЛ (ДАННОЕ СУЖДЕНИЕ ДВУСМЫСЛЕННО, НО Я ПРЕДПОЛАГАЮ (ИМЕЕТ) ОЗНАЧАЕТ (ИМЕЕТ КАК ЧАСТЬ)) ЧАСЫ С КУКУШКОЙ ИМЕЮТ ЦЕПЬ (ДАННОЕ ПРЕДЛОЖЕНИЕ ДВУСМЫСЛЕННО. ПЕРЕФОРМУЛИРУЙТЕ ЕГО)
Задача, как только она выражена, переносится в ту часть программы, которая может провести обзор всего, что уже случилось раньше. Такая подпрограмма принимает решение на следующем основании:
- Известно ли, что у - часть какого-либо другого объекта? Или у является членом некоторой группы, которая является частью чего-то?
- Известно ли, что у принадлежит кому-то или является членом некоторой группы, которая принадлежит кому-то?
- Если одно из положений (1) или (2) верно, сделайте соответствующий выбор. Если не подходит ни один из вариантов, остановитесь и соберите дополнительную информацию. Если верны оба утверждения, рассмотрите варианты в пункте (4). (Таким образом, программа использует свидетельства того, как ранее полученная информация была включена в "модель" мира.)
- Если вы дошли до этого пункта, значит у уже является частью чего-либо и уже принадлежит кому-то. Нам необходим более точный тест.
Пусть U1 и U2 являются "чем-то" или "какой-то системой), существующими соответственно в ответах на вопросы (1) и (2). Они зависят от у. Теперь спросим: является ли х членом или предметом U1 и U2? Если не подходит ни один из вариантов, остановитесь. Если верен один из вариантов, выберем соответствующий результат - "часть" или "принадлежит". Если верны оба варианта, остановитесь и соберите больше информации. Рафаэль говорит:
"Эти критерии очень просты, но их достаточно, чтобы позволить программе принимать довольно разумные решения с определенной целью в различных предложениях с двусмысленным словом "имеет". Разумеется, программу можно заставить сделать ошибку, например, в случае с предложением "Дик имеет цепь", которое стоит перед предложением "У Джона есть цепь" в приведенном выше диалоге. Однако, когда человек сталкивается с новым миром в похожей ситуации, он наверняка сделает похожую ошибку. Дело в том, что возможно решить проблему двусмысленности в предложении при помощи описания слов в предложениях-описаниях, которые можно создавать автоматически через предварительно приведенные недвусмысленные предложения".
Таким образом, программа составляется так, чтобы попытаться осуществить поиск по ранее собранной информации и найти, каким образом связаны х и у, и связаны ли они вообще. Эту "часть" программы можно воспринимать как своеобразные небольшой суд либо как сбор и анализ доказательств и свидетельских показаний. Не стоит воспринимать ее как процедуру прямолинейно в рамках предварительно обозначенной последовательности решения задачи. Это, скорее, апелляционный суд, который может подсказать, когда программа столкнулась с непоследовательностью или двусмысленностью. Теперь, когда мы будем писать большую программу с большим числом подобных судов, каждый из которых в случае необходимости может призвать другие на помощь, совершенно бессмысленно считать программу "последовательностью". Даже если программист сам сформулировал "законные" принципы, допускающие такие "апелляции", он может не до конца понимать, когда и где в ходе работы программы такие процессы потребуют взаимодействия друг с другом. А что касается отдельно взятого "суда", у него есть лишь обрывочные представления о некоторых обстоятельствах, которые могут привести к такому взаимодействию. Кратко говоря, пройдя уровень новичка, программисты не просто пишут "последовательность инструкций". Они пишут для отдельных случаев из небольших групп или процессов. Но мы довольно редко можем заранее полностью представить себе все детали их взаимодействия. В конце концов именно для этого и нужны компьютеры.
(3) ПРОГРАММА КАК СБОРНИК СОВЕТОВ
Существует заблуждение, которое разделяют не только напуганные гуманитарии, но и большинство компьютерных "специалистов", оно гласит, что программирование по сути - это точная и четкая среда функционирования, основанное на элементарной путанице между формой и содержанием. Если поэтам задали задачу писать строфами по четырнадцать строк, это не сделало бы процесс более точным; если бы композиторы должны были использовать все двенадцать ступеней звукоряда, это бы не ограничило форму в целом; если бы дизайнерам надо было использовать только поверхности четвертого порядка, никто бы этого даже не заметил! Таким образом, просто смешно наблюдать такое единодушие в спорах, что строгая грамматика (старых) языков программирования способствует точности в описании процессов. Действительно, надо очень точно соблюдать правила компьютерной грамматики (синтаксиса), чтобы программа вообще работала. Никаких ошибок в правописании или пунктуации не допускается! Но неправильно утверждать, что это поможет вам четко понять, что именно будет делать ваша программа. В языке FORTRAN, если вы хотите, чтобы ваша программа обращалась к уже написанному процессу, нужно использовать одну из фиксированных команд "ПЕРЕЙТИ" ("GO TO"). Вы не можете сказать "ИСПОЛЬЗОВАТЬ" ("USE") или "ПРИСТУПИТЬ К" ("PROCEED ON TO") и т.п. Синтаксис в этом случае очень строгий. Но вы можете "ПЕРЕЙТИ" практически к чему угодно, поэтому содержание остается свободным.
Еще более неверно предполагать, что такая строгость обусловлена компьютером! Она обусловлена программистами, которые определили язык! В программе Боброва STUDENT можно, если хотите, раз и навсегда ввести "ИСПОЛЬЗОВАТЬ ("USE ") ВСЕГДА ОЗНАЧАЕТ ПЕРЕЙТИ ("GO TO")", и в простых ситуациях вы сможете применить "ИСПОЛЬЗОВАТЬ" вместо "ПЕРЕЙТИ". Разумеется, это - простой пример гибкости, но именно эту мысль большинство людей не принимают: строгость и четкость языка FORTRAN, если она и есть, обусловлена строгим предубеждением, а не строгостью фактов!
В качестве примера современной и более гибкой системы возьмем язык программирования PILOT, разработанный Уорреном Тейтельманом (докторская диссертация в Мичиганском технологическом институте, 1966 г.), позволяет программисту вносить изменения и в свою программу и в сам язык при помощи внешних операторов в языке (текущей версии). Мы зачастую можем называть их "советами", а не "программой", т.к. они написаны между делом и обычно применяются в зависимости от ситуаций по умолчанию или как результат предыдущего совета. Примером может служить следующее суждение, введенное при разработке программы для решения задач вроде хорошо известной загадке "о миссионерах и каннибалах", где лодка может перевозить только двух людей, и т.п.:
В ходе работы, если m - член стороны-1, а c - член стороны-2 и (кол-во m) уступает (кол-ву c ), то выйти. (Более ранняя подборка советов для системы ввода была использована для создания логичного человекоподобного синтаксиса ввода.)
Программа представляет собой эвристический поиск, пробующий различные схемы и движения и предпочитающий те, которые позволяют двигаться вперед, помогая людям переправиться через реку. Сначала Тейтельман пишет базовую программу. Однако, при этом миссионеров съели, а вышеуказанный "совет" рекомендует "изменить часть программы для измерения движения вперед, чтобы отклонить перемещения, после которых на берегах реки остается неравное количество миссионеров и каннибалов". Как утверждает Тейтельман:
При этом для ПРОДВИЖЕНИЯ создаются условия "поедания". Недостаточно просто считать и сравнивать, поскольку, когда все каннибалы находятся на одном берегу, а миссионеры - на другом, они превышают количество миссионеров в соотношении 3 к 0. Но никто при этом не съеден.
Однако, дело вовсе не в снижении синтаксических ограничений. Дело - в "консультативном" характере изменений, внесенных в программу. Суждение о "продвижении вперед" можно высказать, не зная, как осуществляется это "продвижение" и где именно оно находится в "программе". Ситуация может меняться под действием другого совета, причем вы можете даже не представлять себе, когда будет использован новый совет, а когда на него просто не обратят внимания. Под воздействием советов может измениться совсем другая функция, в некоторых ситуациях вообще не будет никакого "продвижения" и кто-то может быть съеден в любом случае. Если это случилось, надо будет попытаться понять, почему.
У вас будут возможности (1) для глубокого понимания существующей программы и "исправления" ошибки или (2) ввода нового предложения-совета с описанием, в чем могла бы быть проблема в данной ситуации, где программе приказывают не перевозить миссионера в то место, где его съедят. Постепенно программа набирает силу и эволюционирует, благодаря таким вставкам в программу. Программист при этом начинает терять нить внутреннего содержания и больше не может предсказать, что случится. Он начинает надеяться, не опираясь на знания, наблюдает за программой, как будто это человек с непредсказуемым поведением.
Такое уже случается в некоторых больших программах. Однако, по мере того как мы входим в эру многофункциональных компьютеров с возможностями управления с нескольких точек, проблема вскоре будет более острой. В режиме разделения времени несколько программистов будут разрабатывать и модифицировать большие эвристические программы, причем каждый будет тестировать программы на разных примерах с разных терминалов для управления, вставляя собственные советы. Программа станет более эффективной, но никто из программистов этого не поймет. (Разумеется, не всегда это будет приводить к успеху, подобные взаимодействия могут только все испортить, и никто уже ничего не сможет исправить!) Теперь мы видим настоящую проблему заявлений типа "машина делает только то, что ей говорит программист". Больше не существует одного единственного программиста.
СВОБОДА ВЫРАЖЕНИЯ И ОГРАНИЧЕННОСТЬ ИДЕЙ
Наконец мы подошли к вопросу, что делать, когда нам надо написать программу, но при этом мы не до конца представляем себе, что надо сделать и как. Ложный вывод, который только отдаляет всех от решения проблемы, очень прост:
- Главная предпосылка: Если я напишу программу, она будет делать что-то частное, поскольку каждая программа выполняет что-то определенное.
- Малая предпосылка: Моя идея неясна. У меня в голове нет определенного результата.
- Вывод: Следовательно программа не будет делать то, что я хочу.
Итак, все думают, что в программах нельзя выражать нечеткие идеи.
На самом деле существуют два заблуждения. Во-первых, недостаточно сказать, что у вас в голове нет четкого результата. У вас есть набор плохо сформулированных приемлемых функциональных характеристик (операций). Вы будете рады, если машина может выполнять задачи в этом диапазоне. Чем шире диапазон, тем шире свобода задач программы. Не обязательно все сводить на нет: даже если кто-то напишет определенные слова или инструкции, другой все равно в праве считать эту программу отдельным примером. В этом смысле можно считать отдельную написанную историю частным случаем концепции, которая по-прежнему нечетко выражена в сознании автора.
Это может прозвучать как увертка или уклончивый ответ. В каком-то смысле это так. Второе заблуждение касается утверждения, что надо записать отдельно взятый процесс. При всей своей неуверенности я имею полное право указывать не отдельные процессы, а генераторы процессов, правила выбора, "суды" и "советы" для выбора и т.п. А значит, поведение имеет широкое поле выражения оно никогда не пойдет дважды по одному и тому же пути и его можно заставить проявиться в тех же допустимых рамках в сознании автора.
И здесь можно возразить в последний раз: а находится ли оно в этих рамках? Помните, я не говорю о том, что программирование - простой способ выразить плохо сформулированные идеи! Чтобы в полной мере воспользоваться удивительной гибкостью этого средства, необходимы огромные технические, интеллектуальные и эстетические навыки. Очень сложно загнать поведение программы в какие-то определенные рамки. Точно также писателю нужны определенные навыки, чтобы выразить определенную степень двусмысленности. Компьютер подобен скрипке. Можете представить себе новичка, сначала опробовавшего проигрыватель и только затем - скрипку. И звук последней, по его мнению, ужасен. Именно такой аргумент мы слышали от гуманитариев и многих специалистов в области информатики и компьютерной техники. Они считают, что компьютерные программы достаточно хороши, но недостаточно гибки. То же самое можно сказать и о скрипке и о пишущей машинке, пока вы не научились ими пользоваться.