К вопросу об автоформализации профессиональных знаний и ее инструментах

Цейтин Г.С.

Эти заметки связаны с задачей массового использования ЭВМ в разнообразных видах профессиональной деятельности, как она обрисована в книге Г.Р. Громова «Национальные информационные ресурсы», а также в его статье («Микропроцессорные средства и системы», N 3, 1986) и имеют целью уточнить некоторые используемые при этом понятия и постановки задач, а также предостеречь от некоторых расхожих упрощений в понимании этих задач.

Можно полностью согласиться со словами Г.Р. Громова:

«Как превратить ЭВМ в эффективный инструмент программирования для непрограммирующих профессионалов – актуальный вопрос технологии программирования в восьмидесятые годы, от ответа на который зависят масштабы и эффективность внедрения вычислительной техники». Кажущееся противоречие – «инструмент программирования для непрограммирующих профессионалов» – не должно смущать. Непрограммирующие профессионалы – это представители всех профессий, нуждающиеся в использовании вычислительных средств (чтобы избежать каламбуров, будем их здесь именовать специалистами). Их непосредственный контакт с машиной – это единственный мыслимый способ обеспечить решение на ЭВМ необходимых задач: никаких программистов, которых можно было бы привлечь в качестве посредников, очевидно, не хватит на все применения машин. Реальный вопрос в том, какими инструментами надо снабдить для этого специалистов и как в этом случае будет выглядеть их деятельность. Другой вопрос – каковы задачи профессиональных программистов в обеспечении этого процесса.

В понятие автоформализации профессиональных знаний по Г.Р. Громову входит, как можно судить, не только решение задач на ЭВМ непосредственно специалистом, но и передача создаваемых при этом средств (программ) другим специалистам в той же области или даже потребителю, не являющемуся таким специалистом. Если это происходит, то мы можем считать, что в созданном средстве действительно материализована определенная часть профессиональных знаний и опыта специалиста.

Но, вероятно, было бы неправильным говорить, что мы имеем дело только со знаниями. Опыт показывает (и это неоднократно отмечается Г.Р. Громовым), что обычно наибольшую трудность представляет не выделение знаний о способах обработки данных в ЭВМ (используемые формулы порой совершенно элементарны), а выделение потребностей специалиста, или шире, проектирование всего процесса деятельности специалиста с использованием ЭВМ или же функционирования автоматической системы с ЭВМ в контуре управления. Процитированные Г.Р. Громовым слова Д. Цихрициса «Определить, что хочет пользователь в отличие от того, что он говорит, что он хочет, – это и есть настоящее искусство» отражают хорошо известную ситуацию. Это один из наиболее сложных вопросов разработки прикладных программных средств, даже если он решается в сотрудничестве специалиста и профессионального программиста. К вопросу о методах и инструментах решения этой задачи мы еще вернемся.

Еще сложнее положение, когда ставится задача переноса на ЭВМ человеческих функций, основанных не на собственно знаниях, а на невербализованных навыках. Лично я не разделяю энтузиазма Г.Р. Громова по поводу водителя вездехода в тайге, который попытался бы запрограммировать проводку вездехода через хорошо знакомое болото. С этой задачей «в лоб», без серьезной исследовательской работы, думаю, не справился бы ни водитель, ни программист, ни они оба вместе, хотя эта задача и приводится как пример задачи на автоформализацию профессиональных знаний. Возвращаясь из тайги за свой стол, я могу предложить другую задачу: страницу рукописного текста (уже представленную в виде растра из черных и белых точек с подходящим разрешением) преобразовать в побуквенную кодировку этого текста. Лично я сейчас не взялся бы за такую задачу, хотя неплохо разбираю чужие почерка, да и программирую давно. Интересно, как охарактеризовал бы эту задачу Г.Р. Громов, если он считает недопустимым говорить, что задача не созрела для автоматизации. Думаю, что ЭВМ – не панацея, кто бы ни брал ее в руки: специалист или программист.

Требует уточнения и использование термина «формализация». В рамках общей постановки задачи Г.Р. Громов не вполне дифференцированно использует понятия демократизации знаний (отчуждения их от узкого круга жрецов), математизации и формализации. Очевидно, могут широко распространяться, в том числе при помощи средств массовой информации, не только формализованные и математизированные знания. Математизацию тоже нельзя рассматривать как универсальную форму научности. Само представление о предмете математики и ее облик менялись с появлением каждой новой сферы приложений. Не избежала она этого и в наше время, в том числе в связи с развитием вычислительной техники. В частности, на нынешнем этапе использование чисел уже не является необходимым атрибутом математизации. С сегодняшних позиций необходимым условием математизации является формализация, под которой, по-видимому, надо понимать возможность полного перечисления всех объектов и соотношений, участвующих в постановке задачи, так чтобы ее решение оставалось полезным, несмотря на отвлечение от остальных реально присутствующих факторов. Формализация не тождественна математизации: последняя предполагает не только получение формализованного описания задачи, но и использование таких методов преобразования полученной информации, которые могут дать результат, не получающийся без формализации.

Для понимания ситуации в программировании важно иметь в виду, что в нем мы имеем дело как с математизированными, так и с нематематизированными областями знания. Напротив, формализация всегда необходима для ввода задачи в вычислительную машину, хотя эта формализация может быть и совсем неглубокой, т.е. отражать слишком малую часть существенных для задачи факторов (например, можно свести литературное произведение всего лишь к последовательности букв и знаков препинания).

Нужно также учесть, что процесс решения задачи на вычислительной машине сегодня достаточно сложен и уже не может рассматриваться как полностью формализуемый. Мы не можем сказать, что, работая на реальной машине, мы способны перечислить все факторы, влияющие на результат. И не потому, что реальные машины иногда дают сбои, а потому, что одна и та же программа используется на многих машинах, отличающихся либо конструктивными особенностями, либо вообще всей архитектурой (для программ, написанных на машинно-независимом языке). Точно перечислить условия, необходимые для того, чтобы некоторая реальная программа функционировала в соответствии с ее замыслом, нереально. Ведь на применимость программы может повлиять даже различие в диапазоне и точности представления чисел, не говоря уже об особенностях используемых версий языка, операционной системы, периферийных устройств и т.д. К огорчению энтузиастов доказательного программирования приходится отметить, что здесь мы имеем дело не с математической моделью, где можно что-то доказывать, а непосредственно с жизнью. Доказательное программирование часто рассматривается как ключ к надежности программных средств, но ни в каких реальных изделиях (не только в программах) мы не имеем ни абсолютно точной спецификации, ни абсолютной надежности. Скажем, в инструкции к огнетушителю не говорится, на какой в точности угол следует поворачивать его ручку при запуске, а если он почему-либо не срабатывает, то скорее всего не из-за ошибки в угле. Может быть, вместо термина «формализация» лучше подошел бы термин «кодирование».

Трудно согласиться и с тезисом Г.Р. Громова о том, что стремление к самостоятельному выходу специалиста на ЭВМ связано с исчерпанием значительной части ранее формализованных знаний. С одной стороны, даже наличие ранее известной формализации определенных специальных знаний не всегда избавляет специалиста от необходимости самостоятельно переносить их в ЭВМ, с другой стороны, использование ЭВМ для отражения ранее не формализованных знаний или решений имеет давнюю традицию. Оно ведет начало, по крайней мере, от коммерческих и управленческих применений ЭВМ, возникших еще в пятидесятые годы. И к тем же временам относятся попытки создания языков, позволяющих записывать программу в виде, непосредственно доступном для восприятия специалиста (фраза из давней американской рекламы: «наш язык так прост, что даже ваш босс поймет его»). Заметим еще, что подобные применения ЭВМ уже на раннем этапе стимулировали развитие алфавитных устройств ввода-вывода (в чем наша страна, не развивавшая тогда таких применений, отстала): первой по алфавиту «национальной литерой» в ИБМ-овском коде является знак доллара, неизменно присутствующий на всех алфавитных устройствах. Влияние алфавитной формы представления информации на облик современного программирования трудно переоценить. С другой стороны, снижение роли математизированных знаний в программировании действительно наблюдается в последнее время, но не столько из-за того, что подходят к концу его прежние запасы, сколько потому, что в сферу применения ЭВМ входят такие области человеческой деятельности, где математизированных знаний и не было.

Итак, в термине «автоформализация профессиональных знаний» по крайней мере две составляющие – «знание» и «формализация» не вполне точны. Тем не менее будем использовать этот термин ввиду отсутствия другого.

Далее, самостоятельный выход специалиста на ЭВМ нельзя рассматривать как исключительную особенность нынешнего этапа в программировании. С тех пор, как машины стали сколько-нибудь доступны, среди специалистов всегда находились энтузиасты, готовые самостоятельно преодолеть все трудности обращения к ЭВМ ради решения своих профессиональных задач. Тем не менее нынешний период использования вычислительной техники имеет свою отличительную черту – это создание средств программирования, рассчитанных именно на специалистов (первым таким средством являются сами персональные ЭВМ, предназначенные для этого потребителя).

Если на прежних этапах предполагалось, что, как правило, пользователю-непрограммисту передается законченная, замкнутая в себе программа, решающая его задачи, то теперь появилась необходимость передавать ему средства, которые он мог бы сам дорабатывать в соответствии с содержанием своих конкретных задач. Прежде четко просматривалось деление программных средств на средства, обслуживающие программиста (трансляторы и другие «системные» программы), и средства, обслуживающие пользователя (проблемные программы). При этом первые использовали довольно широкие возможности доступа к разнообразным ресурсам машины и обладали достаточной свободой в манипулировании данными разнообразной структуры, в то время как для вторых, пользовательских программ это все считалось ненужным. Разработчики языков программирования и трансляторов сознательно ставили проблемных программистов в узкие рамки, высокомерно полагая, что им большее и не понадобится (к этому еще добавлялось, что ограничения вводятся в интересах самого пользователя, ради надежности). Другими словами, сложился разрыв между возможностями, используемыми при программировании «для себя» (вернее, для себе подобных) и программировании «по контракту».

В современных условиях сфера контрактного программирования вынужденно сужается; в частности, практика создания крупных систем по предварительно разработанным спецификациям, зафиксированным в соответствии с лучшими традициями американского менеджмента, оказалась несостоятельной (Дж. Мартин, «Разработка приложений без программистов»). В соответствии с этим приходится пересматривать и подход к созданию программных средств для специалистов.

Если мы передаем обращение к ЭВМ в руки самого специалиста, ставящего задачу, то он, естественно, должен получить инструмент с более широким диапазоном возможностей, чем составленная кем-то прикладная программа для решения единичной задачи. Более того, если он в программировании становится хозяином, то его могут не удовлетворить и те ограничения, которые ранее представлялись естественными в «проблемном» программировании. И не потому, что ему невтерпеж «дорваться» до всяких манипуляций с данными и до «потрохов» операционной системы (хотя некоторые специалисты порой вынуждены идти и на это; я встречал социального психолога, который без колебаний лез с отверткой в неработающий дисковод). Дело прежде всего в том, что, став постоянным хозяином своей обработки данных, он должен ориентироваться не только на те структуры данных, которые порождаются предоставленной ему системой программирования, но и на те, которые он может получить извне; ему необходимо накапливать не столько законченные программы, сколько их части, которые могут быть использованы впоследствии, и для этих частей должен быть предусмотрен законный статус в его системе; он может не удовлетвориться положением, при котором всю программу нужно фиксировать заранее, до ее пуска, а во время работы уже нельзя импровизировать или автоматически вызывать новую программу в зависимости от получаемых результатов; ему больше, чем профессиональному программисту, потребуются богатые возможности графических средств, и т.д. При всем этом инструмент, предлагаемый специалисту, не должен требовать от него программистского образования, он должен дать ему возможность работать в собственной системе понятий.

Еще одна функция инструмента программирования для специалиста связана с тем, что он не может знать заранее точных требований к своей программе. Единственное, что можно здесь предложить – это эксперимент, т.е. построение и испытание предварительного варианта («макета») требуемой программы. Г.Р. Громов поясняет, что ведущие американские специалисты по организации программных разработок «открыли» этот путь лишь в 1981 г. Впрочем, для тех, кто непосредственно занят разработкой новых систем как «хозяин», это всегда было хорошо известной истиной; опытный разработчик знает, что даже если нет возможности создать макет малыми усилиями, он должен в конструкцию создаваемой системы заложить возможность ее достаточно быстрой модификации, тогда макетом послужит первый вариант системы. То, что об этом так поздно стали писать специалисты по организации разработок, свидетельствует лишь о косности их науки и отрыве разработок «большой» промышленности от исследовательских работ (кое-кто упорно стремится воспроизвести такой отрыв у нас). В наших условиях утверждению макетного подхода помешала затянувшаяся практика адаптации чужих систем, при которой спецификации поступали с самого начала в готовом виде или выражались в наличии действующего прототипа. В результате наш ГОСТ «Стадии и этапы разработки» не упоминает ни макетирования, ни пересмотра спецификаций по результатам опытной эксплуатации первоначального образца.

Как бы то ни было, инструмент для специалиста должен обеспечивать быстрое экспериментирование с вариантами системы. Скорее всего, в условиях, когда лимитирующим фактором являются не ресурсы оборудования, а время разработчика, не будет резкой границы между макетом и рабочим вариантом – рабочий вариант будет результатом последовательного усовершенствования макета. Поэтому инструмент для специалиста должен обеспечивать легкость модификации системы, возможность широкого использования ранее заготовленных элементов, простоту сборки готовой программы или замены ее элементов.

Таким образом, создание адекватного инструмента для специалиста – это многосторонняя и далеко не полностью решенная задача. Во всяком случае, ее нельзя решить, просто урезая возможности средств, созданных ранее для профессиональных программистов.

Ни решение, ни даже постановка такой задачи не могли возникнуть в готовом виде в момент, когда персональные ЭВМ стали экономически доступными для массового специалиста. Поэтому такие машины оснащались средствами программирования из числа имевшихся. Естественно, выбиралось то, что было пригодно для первых персональных ЭВМ по ресурсоемкости, а кроме того, было не слишком сложно для понимания неподготовленного в программировании специалиста. В этом, по-видимому, причина распространения Бейсика и подобных языков. Альтернативой универсальным языкам обычного типа явились средства, работающие в системе понятий специалиста, но жестко ориентированные на конкретные типы задач и оставляющие мало места для собственно программирования – это прежде всего разнообразные системы автоматизации конторской работы.

Г.Р. Громов рассказывает об успешном опыте автоматизации микробиологического эксперимента, где программирование было выполнено в основном силами самих специалистов, быстро овладевших языком Бейсик и затем в его терминах ставивших профессиональным программистам задания на включение в систему дополнительных внешних функций. В этом опыте стоит отметить две принципиальные особенности: во-первых, основой автоматизации явился не Бейсик в чистом виде, а созданная на его базе система с включенными внешними функциями, т.е. имела место доработка стандартной системы программирования под требования заданной проблемной области, во-вторых, эта доработка проводилась в условиях взаимодействия специалистов и профессиональных программистов. Кроме того, было отмечено, что в данном случае общей системой понятий для взаимодействия между двумя категориями профессионалов явилась система понятий языка Бейсик.

Хотелось бы отметить, что усвоение этой системы понятий специалистами – это для них не только приобретение, но и потеря. В процессе разработки и отладки они научились строить такие программы, смысл которых они не могли бы четко сформулировать программисту. Что этот смысл не удастся объяснить программисту, может быть, и не так страшно, но важно другое: сменив свою профессиональную систему понятий на понятия языка программирования, сможет ли специалист вернуться к своей системе после того, как после многочисленных попыток он запрограммировал свой 9-й или 12-й вариант? Сможет ли он впоследствии правильно разобраться в том, какие знания или решения отражает его программа, хотя бы и успешно проработавшая? Сможет ли он объяснить принципы работы этой программы своему коллеге, чтобы тот мог повторить или видоизменить эту программу, или же он сможет лишь дать коллеге копию готовой программы? (Э. Дейкстра иронизировал, что, если раньше физики повторяли эксперименты своих коллег, то теперь они заимствуют программы на Фортране, вместе с ошибками.) Иначе говоря, не приведет ли вынужденная привязка своей работы к машинно-ориентированным понятиям к деформации его профессионального мышления? И другая группа вопросов. Сможет ли он экстраполировать свой опыт разработки системы не очень большого размера на последующие разработки более крупных систем? Сможет ли он объяснить определенный участок своей программы профессиональному программисту, когда окажется, что именно этот участок оказался критичным по ресурсам и его требуется оптимизировать? (Возможности эквивалентного преобразования программ без дополнительных сведений о программе и данных крайне ограничены.)

Не надо понимать эти вопросы как критику конкретно языка Бейсик в пользу излюбленных теоретиками языков, основанных на принципах «структурного программирования». Главное в том, что, если мы переходим к добыванию и накоплению знаний в машинно-выполнимой форме, то насколько удобна эта форма знания для последующего развития, для передачи от одного человека к другому. (Пока что машины сами науку не развивают.) Отражает ли структура получаемого машинного объекта структуру понятий той науки, для задач которой он создан? Структурное программирование, конечно, частично решает эту задачу, обеспечивая сам факт структурированности программы и связь ее структуры со структурой математических утверждений о программе. Но это, конечно, не полное, да и не единственно возможное решение задачи.

Для примера можно вспомнить об одной из разновидностей Р-технологии, где для программирования обработки синтаксически организованных текстов используются структуры, отражающие синтаксическое строение этих текстов. Такое положение вообще свойственно системам построения трансляторов. Их пример заставляет задуматься о следующем: почему профессиональные программисты для одной из областей своей собственной деятельности нашли адекватную форму представления задач, а представителям других специальностей не предлагают ничего, кроме урезанных языков универсального типа? Оправдать программистов могло бы лишь то, что они не имели возможности глубоко узнать проблемы других специалистов, но отсюда следует, что рекомендованного Г.Р. Громовым общения специалистов с программистами в терминах языка Бейсик недостаточно.

В дополнение к рассказу Г.Р. Громова о разработке ППП «Микроб» позволю себе рассказать о собственном опыте сотрудничества со специалистами, именно с лингвистами, продолжающегося уже почти 30 лет (отсюда видно, в частности, что проблемы взаимодействия специалистов с программистами возникли задолго до нынешнего этапа развития вычислительной техники).

Сотрудничество математиков (тогда программисты еще не выделялись) и лингвистов первоначально концентрировалось вокруг задачи автоматического перевода с одного языка на другой. Интерес лингвистов к этой задаче в то время стимулировался не только надеждой на скорый практический результат (как теперь ясно, несостоятельной), но и внутренней логикой развития лингвистической науки, которая к этому времени успела сделать существенные шаги в направлении формализации своих понятий и законов. Кое-кто надеялся даже, что в условиях существовавшего в лингвистике разнобоя в понятиях и суждениях машина сыграет роль объективного судьи. А некоторые математики считали своим долгом на материале этих задач «воспитать» лингвистов, приучить их к точному мышлению, порой навязывая им собственные понятия или даже ограничения тогдашней техники программирования в качестве непреложных требований. Ставился также вопрос, кто собственно должен составлять алгоритмы перевода: сами лингвисты или математики с консультацией лингвистов.

Один из ранних подходов к задаче автоматизации перевода состоял в том, что предлагалось проанализировать, как это делает человек, и воспроизвести в программе ту же последовательность решений и действий. Пытались, в частности, воспользоваться опытом некоторых преподавателей иностранного языка, которые в помощь студентам, неспособным сразу схватить смысл предложения на иностранном языке, разрабатывали формальные схемы анализа (например, как найти сказуемое). Тогда была популярной аналогия с определителями растений, используемыми в ботанике: для определения вида неизвестного растения дается большой список нумерованных правил, в каждом из которых проверяется некоторый признак и задаются переходы к другим номерам в зависимости от результата. Предполагалось, что лингвист сможет составить аналогичный определитель для предложений, а потом осталось бы только его запрограммировать. Однако столь очевидный путь «автоформализации профессиональных знаний» не привел к успеху. Разнообразие всех встречающихся случаев, вариантов и исключений просто не удавалось удовлетворительно охватить подобной схемой.

Причина была в том, что эта форма не соответствовала сложившейся системе лингвистических знаний. Лингвисты умели описывать текст не в терминах букв, слов и знаков препинания, а с использованием более глубоких понятий, таких как члены предложения, грамматические конструкции, части речи, падежи, времена и т.п. Все эти важные для перевода понятия не даны непосредственно в исходном тексте, их определения у разных лингвистов существенно расходились, что приводило к попыткам объявить их вообще неточными, ненаучными, ввести вместо них какие-то случайные признаки, якобы мотивированные реальной задачей. В качестве ответной реакции некоторые консервативные лингвисты объявляли все это направление ненаучным. На самом деле, конечно, никакие понятия, придуманные под сиюминутную необходимость, не решали задачи. Опыт привел к использованию понятий, обладающих реальным лингвистическим смыслом; эти понятия были существенно уточнены по сравнению с традиционными, но, конечно, не порывали с прежним лингвистическим опытом, а развивали его. Однако описание задачи анализа или перевода текста на основе этих понятий уже не выглядело как непосредственно заданный алгоритм, хотя могло и содержать алгоритмические элементы.

В этих условиях перед математиками (или программистами) стояла задача выработки формального аппарата, способного представить в машине заданное лингвистами описание и преобразовать его в алгоритм (или построить общий алгоритм интерпретации лингвистического описания). Создание такого аппарата проходило в разных коллективах по-разному, инициатива могла исходить как от лингвистов (уже продвинувшихся в уточнении собственных понятий и усвоивших элементы дискретной математики), так и от математиков (частично обучившихся основам лингвистики и конкретным языкам). В каждой конкретной создававшейся системе учитывались не только лингвистические потребности, но и ограниченные возможности алгоритмизации и программирования, так что всегда имели место и сотрудничество, и компромиссы.

Удовлетворительного решения задачи автоматического перевода мы не имеем и сегодня. Теперь ясно, что в полном объеме ее и нельзя решить в отрыве от всего комплекса задач машинного представления знаний. Однако известны достаточно убедительные результаты, например, в переводе на синтаксическом уровне или в понимании машиной языка в рамках жестко ограниченной проблемной области.

В приведенном мной примере при хорошо налаженном сотрудничестве лингвисты, хотя и не пользуются персональной машиной (просто дело не дошло до таких машин), полностью являются хозяевами своей задачи, сами пишут свои правила на выработанном языке, испытывают их, анализируют ошибки и исправляют их. Они могут также высказывать программистам пожелания относительно модификации используемой системы. В целом взаимодействие носит тот же характер, что и в примере Г.Р. Громова, и можно считать, что основные фазы описанного им технологического цикла взаимодействия сохраняют силу. В обоих случаях происходит полное исключение программистов из стандартного цикла решения задач на ЭВМ, но теперь вместо составления каждой конкретной программы программисты занимаются общей организацией взаимодействия специалиста с машиной. Различие между двумя случаями в том, что для лингвистов были выработаны специальная модель проблемной области и ориентированный на нее язык, приближенные к лингвистическим понятиям, в то время, как микробиологам пришлось пользоваться в качестве основы случайно попавшим в руки языком. К тому же Бейсик, как и все традиционные языки, создан в расчете в первую очередь на программирование формульных вычислений, т.е. на уже математизированные знания, а не на освоение новых областей.

Заметим, что разнообразные ориентированные на пользователя системы автоматизации конторской работы (например, те, что описывает Дж. Мартин в уже упомянутой книге) также ориентированы на понятия пользователя и удобный для него способ взаимодействия с машиной. Возможно, существующие системы недостаточно открыты для развития силами пользователей, а также не приспособлены к взаимодействию с системами для специалистов других профессий (например, через общую базу данных) и с программами, написанными на традиционных языках программирования, но развитие в этом направлении вполне вероятно. Успехи в использовании таких систем позволяют предполагать, что этот путь обеспечения доступа специалистов к ЭВМ действительно перспективен. (Ранней формой таких проблемно-ориентированных систем являются пакеты прикладных программ.)

Иначе говоря, необходимо устранить разрыв между двумя типами программного обеспечения для персональных машин: замкнутыми системами, полностью приспособленными к задачам пользователя, но почти не дающими средств для самостоятельного программирования, и системами, ориентированными на программирование, но принуждающими мыслить в специфически машинных терминах. Специалиста нужно освободить от работы с такими техническими понятиями, как машинные слова, массивы и условные передачи управления и, может быть, даже от знаменитых «трех китов» структурного программирования («;», «if» и «whilе»), оставив за ним собственно интеллектуальное конструирование на основе объектов, имеющих смысл в его собственной предметной области. Программистские инструменты для создания таких систем можно найти (одним из возможных путей является использование систем типа Smаlltаlk 80). Трудность в отборе и уточнении объектов, задач и форм их представления, пригодных для конкретных проблемных областей.

Каким же образом можно обеспечить создание и развитие таких проблемно-ориентированных систем для самых разных специальностей? Одна сторона этого вопроса – это роль программистов в такой работе, требования к их квалификации, их инструментам, научные основы такой деятельности. Кроме той ситуации, когда программист тесно сотрудничает со специалистами и сам в значительной степени специализируется, возможен и другой путь, когда программисты самостоятельно прогнозируют возможные потребности специалистов и разрабатывают систему для них, еще не зная точно, кто ей воспользуется и найдет ли она широкое распространение. (Обращаться к специалистам с прямым вопросом, чего они хотели бы, бессмысленно: они все равно не знают возможностей и в лучшем случае попросят о расширении какой-либо уже известной им системы, что на самом деле вовсе не лучшее решение.) Кстати, интересно, как можно охарактеризовать такую форму работы программистов с позиций разделения программирования на «контрактное» и «хозяйское»: здесь программируют не для себя, но и не по заказу; получается, так сказать, конфекцион вместо индивидуального пошива. На этом пути, конечно, вполне вероятны неудачи: не случайно говорят, что большая часть созданных прикладных пакетов не находит применения. Но этот путь, в общем, не бесплоден – распространенные языки программирования и операционные системы создавались именно в таком режиме.

Практика создания проблемно-ориентированных систем и средств взаимодействия с пользователем, пока не очень обширная, несомненно потребует и обобщения, и теоретического осмысления. Среди учитываемых здесь факторов нужно выделить, с одной стороны, когнитивные, связанные с возможной структурой системы понятий в проблемной области и способами установления соответствий между этими структурами и уже освоенными программированием машинно-ориентированными структурами, с другой стороны, психологические факторы, связанные с удобством для пользователя выбранных форм его взаимодействия с системой, с выбором способов представления информации, вводимой и воспринимаемой пользователем, с производительностью его труда при работе с системой. Эта область пока еще мало исследована. Могу сослаться на свой опыт (мне приходилось заниматься построением проблемно-ориентированных систем не только для задач обработки текстов на естественном языке, но и для разнообразных задач меньшего масштаба): мне не раз приходилось обнаруживать, что для установления соответствий между системой понятий, естественной с точки зрения проблемной области, и обычными математическими или программистскими структурами требуются средства, довольно неочевидные, а порой и не укладывающиеся в рамки традиционного логико-математического подхода к описанию семантики проблемных областей. Видимо, предстоит сделать еще немало подобных открытий.

Другой вопрос, связанный с задачей создания проблемно-ориентированных систем для специалистов – это вопрос об участии самих специалистов в этой работе и необходимой для этого подготовке. Прямого ответа на этот вопрос, по-видимому, нельзя дать, потому что от специалиста здесь требуется формирование в своей области или хотя бы на ее малом участке стройной системы понятий, поддающейся отображению на средства вычислительной техники. Систематизация понятий в своей предметной области – это работа, требующая наивысшей научной квалификации. Однако можно ставить вопрос о повышении общего уровня подготовки специалиста в вопросах использования ЭВМ. Очевидно, ему необходимо понимание общих возможностей автоматической обработки информации и их ограничений, возможностей хранения информации и ее передачи между машинами, а также между человеком и машиной, общих количественных ограничений на возможности технических средств, общих форм структурирования программного обеспечения и расширения ранее построенных систем новыми средствами. Нужен, конечно, практический опыт в использовании и, возможно, расширении простых систем (хотя бы игровых). Если же говорить не о том специалисте, который разрабатывает новую систему (пилот-пользователе), а о том, который только использует средства, созданные его коллегами, то требования могут быть и ниже.

Эти соображения, очевидно, имеют близкое отношение к бурно обсуждаемому вопросу о содержании понятия всеобщей компьютерной грамотности и требованиях к учебным программам для школы и ликбеза. Существующий учебник информатики для 9-го класса подвергается критике за то, что он вместо обучения навыкам работы на реально существующих системах (т.е. практически – на Бейсике и на микрокалькуляторе «Электроника Б3-34») предлагает общие понятия, используя «ненастоящий», «выдуманный» язык. С изложенной выше позиции даже предлагаемые в этом учебнике понятия структурного программирования могут оказаться слишком специальными для непрограммистов, хотя их общеобразовательная ценность не вызывает сомнений. Что же касается Бейсика, Б3-34 и подобных средств, то, конечно, владение конкретным инструментом всегда полезно, однако вызывают серьезную тревогу попытки свести к этому все обучение использованию ЭВМ. Если оценивать их с точки зрения перспектив развития вычислительных средств, то эти навыки не имеют ничего общего с тем, что понадобится специалисту в будущем. Сегодняшняя их популярность в значительной степени стимулируется даже не их практической полезностью, а желанием поскорее отчитаться в решении актуальной задачи. Превращение программирования для Б3-34 в своего рода спорт с погоней за мелочной экономией тактов уводит внимание от серьезных задач в сторону тех самых «реликтовых критериев», о которых пишет Г.Р. Громов.

К сожалению, представление, что такими элементарными средствами и исчерпывается вся суть программирования, поддерживается и некоторыми серьезными специалистами, которые по многолетнему опыту своей работы привыкли смотреть на программистов как на каких-то подсобных рабочих, не имеющих отношения к существу решаемых задач. Сегодня организации, следующие такому подходу, не могут эффективно использовать вычислительную технику, и не столько потому, что квалифицированный программист не станет задерживаться в такой организации, сколько потому, что специалист, относящийся к программисту таким образом, сам не сможет грамотно поставить перед ним задачу. Он не может оценить не только эффективность того или иного варианта или возможность использования ранее созданных средств, но и потребности в будущей модификации требуемой программы, которые могут возникнуть в процессе ее использования, необходимость учесть с самого начала в конструкции создаваемой программы ее сопряжение с другими средствами и многое другое. Он и не стремится к этому, полагая, что программист будет каждый раз делать все заново, а уважать его труд необязательно.

«Система Бейсик разрушает буквально на глазах глубоко укоренившийся миф о недоступности ЭВМ непосвященным» – пишет Г.Р. Громов. Не знаю, как насчет мифов, а самоуверенность непрофессионалов тоже не приносит пользы. Если я могу самостоятельно собрать детекторный приемник или привинтить ручку к телевизору, то я не стану претендовать на диплом радиотехника или тем более на конструирование радиолокационной системы для противовоздушной обороны. Если я смогу морально поддержать попавшего в беду знакомого, то это еще не основание считать себя психотерапевтом и широко предлагать свои услуги. Почему же к программированию подходят с другой меркой? Бейсик может создать иллюзию быстрого успеха, пока составляются совсем небольшие программы. Если специалисту ничего другого не нужно, то большой беды нет. Но хуже будет, если он начнет в таком же стиле писать большую систему. Не из-за того, что он не умеет писать эффективно в смысле ресурсов машины, а просто он завязнет в ошибках и несоответствиях, как пресловутый динозавр в асфальтовом болоте. К сожалению, это все трудно объяснить при обучении, потому что обучение всегда начинается на простых примерах, а на них ничего не доказать. Тот, кто ранее обучился Бейсику, попытается направить решение любой учебной задачи на привычный путь и будет сопротивляться любому другому подходу. Остается только повторить, что лучше вместо Бейсика дать специалисту средства его уровня. Снова аналогия с бытовой радиоаппаратурой: она сейчас имеет достаточно много кнопок, индикаторов и соединительных шнуров со штекерами, но я не должен знать, сколько контактов включает и выключает нажимаемая мной кнопка и сколько проводов проходит внутри шнура, который я воспринимаю как одно целое.

Красной нитью через разделы книги Г.Р. Громова, посвященные автоформализации и науке программирования, проходят его весьма нелестные высказывания, адресованные профессиональному программированию и программистской науке. Профессиональное программирование он обвиняет в элитарности, в корпоративной позиции по отношению к реальным задачам, в приверженности безнадежно устарелым критериям эффективности и элегантности программ, да и просто в торможении технического прогресса ради сохранения своих позиций. «Большую науку» программирования он сводит к поискам некоего «перпетуум мобиле», к погоне за утопической мечтой об автоматизации программирования на базе исходных спецификаций, отмечая практическую бесполезность этой задачи даже в случае ее гипотетического решения. Имея нескромность причислять себя как к профессии, так и к науке программирования, я не могу оставить без ответа подобные высказывания.

Если говорить о профессии программиста, то непонятно, чем она хуже любой другой профессии и почему за ней не признается право на использование понятий, не обязательно доступных другим специалистам, или на высокий уровень профессионального мастерства отдельных представителей этой профессии. Мне не приходилось слышать, чтобы обвинение в шаманстве и сокрытии профессиональных тайн адресовывалось выдающимся музыкантам, спортсменам или педагогам.

Насколько я могу судить, такое обвинение возникло не на отечественной почве, и в его истоках лежит, как мне кажется, нервная реакция западных промышленных менеджеров на неожиданное и необъяснимое в рамках их науки проявление индивидуальности наемного работника массового производства, на то, что оказалось невозможным механически заменить одного программиста другим, как рабочего на конвейере, а также что одни программисты могли превосходить других по производительности труда в десятки раз. Вместо того, чтобы по-деловому использовать это новое явление, и разработать организационные формы участия в работе наиболее способных программистов, предусматривающие для них адекватный участок работы, должные права и ответственность, а также вознаграждение, менеджеры стали открещиваться от суперпрограммистов и даже рекомендовать избавляться от них, обрекая их разве что на роль компьютерных преступников. Иные менеджеры, как и некоторые их неумные последователи у нас, пытаются противопоставить шаманству программистов собственное шаманство, и, вероятно, скоро мы вместо обросшей бородой притчи о двух программах («Моей программе требуется только одна секунда на карту» – «Но ваша программа не работает») услышим ее новый вариант:

«Моя программа является промышленным продуктом, изготовленным по утвержденной в установленном порядке технологии» – «Зато моя программа работает».

Порой Г.Р. Громов ставит программистам в вину заблуждения, которые давно уже осознаны и преодолены серьезными профессионалами. Это относится как к обвинениям в ненужной погоне за эффективностью программ, так и к ссылке на высказывание В. Турского из его «Методологии программирования» на с.168 книги Г.Р. Громова. Замечание В. Турского – самокритичный анализ предшествующего опыта; осознание и критика своих ошибок – свидетельство здоровья и развития профессии, а не основание для огульного обвинения. Кстати, перед этим В. Турский замечает, как важно программисту осознавать решаемую задачу в целом, а не только программу, в то время, как пафос автоформализации по Г.Р. Громову в том, чтобы программист вообще не знал реальной задачи, а только писал бы программы внешних функций для Бейсика.

Для обвинения программистов в «корпоративной точке зрения», дающей право на пристрастный отбор решаемых задач, Г.Р. Громов не нашел другого свидетеля, кроме... Козьмы Пруткова. Если какая-то задача «не дозрела» до автоматизации, то это объективный факт, который означает, что над ней необходима дополнительная работа, в том числе с участием программистов. С объективным состоянием предлагаемой сферы применения приходится считаться не только в программировании. Известно, во что выливается поспешная математизация или кибернетизация неготовых к этому областей знания. Кроме того, «недозрелость» может иметь и другие корни: неудачи создания АСУ связаны не только с ошибочной установкой на создание жесткого, неизменного комплекса программ, но и с тем, что такие системы могли подорвать основы существования некоторой категории руководителей.

Что же касается стремления к эффективности программ, то от мелочной гонки за экономией машинных тактов программирование давно излечилось, и сегодня никакой серьезный профессионал не станет тратить силы на такую экономию, если только этого не требуют конкретные особенности задачи. Нужно, однако, заметить, что если бы сейчас вдруг эффективность всех существующих программ по времени и по памяти уменьшилась в несколько раз, то это пришлось бы компенсировать соответствующим увеличением производства всего необходимого оборудования. Если мы ссылаемся на прогресс технологии, ведущий к быстрому удешевлению оборудования, то невредно вспомнить про былую эйфорию «покорителей природы», забывших об ограниченности ее ресурсов. Кроме того, надо считаться и с конкретными условиями: могу вспомнить, как на одной дискуссии Г.Р. Громов, приведя данные о том, что в мире на одного программиста приходится 10 ЭВМ, не смог убедительно ответить на мой вопрос, где же мои десять машин. Нельзя не считаться и с ограничениями объема оперативной и внешней памяти распространенных персональных машин.

Конечно, если прикладнику, заполучившему персональную ЭВМ, вольно использовать ее только для крошечных задач (по сравнению одного журналиста, купив большой чемодан, носить в нем зубную щетку), то он может полностью игнорировать эффективность. Но нельзя забывать, что он может позволить себе такую небрежность лишь потому, что его программа работает на базе профессионально созданного исходного программного обеспечения, и было бы гораздо хуже, если бы базовое обеспечение писалось столь же небрежно. Вообще, чем ниже уровень разрабатываемых средств в структурной иерархии программного обеспечения, тем большего внимания требует эффективность.

Достигать экономного использования машинных ресурсов за счет каждый раз особо придумываемых мелких трюков нереально по трудозатратам и неэффективно по результатам. Признанной альтернативой этому является выбор эффективных методов обработки распространенных типов данных и решения типичных задач (искусство программирования, по Д. Кнуту), дополненный рядом более частных приемов программирования, следование которым позволяет систематически добиваться приемлемого уровня эффективности. Владение такими средствами составляет необходимую часть профессионального умения программиста. Другая категория требований, предъявляемых к профессионально написанной программе, – это ее пригодность к использованию в других задачах или других условиях, к поиску и исправлению ошибок, к ее включению в коллективно разрабатываемую систему, к внесению необходимых переделок, к анализу на допустимость использования в каком- либо особом случае и т.п. Эти требования приводят к выработке соответствующего стиля программирования, требующего, в частности, четкости в выделении структурных единиц программы, осмысления их функций и сопряжений с другими единицами, правильного распределения функций между частями, минимизирующего сложность сопряжений, умелого использования ранее созданных средств.

Все эти требования к стилю программирования и лежат в основе сформировавшегося представления об элегантности программы. Требование элегантности является концентрированным выражением целесообразности, а не профессионального снобизма программистов.

Элегантность – это, конечно, не единственное требование к программе. Программист обязан смотреть вперед и предвидеть будущее использование своей программы, ее модификацию, поиск и исправление имеющихся в ней ошибок (даже если в данный момент их присутствие представляется ему абсолютно невероятным). Внесение в программу необходимых пояснений и другие формы демонстрации ее внутренней структуры, введение проверок на ошибки, которые, казалось бы, невозможны, требует от программы определенной избыточности, которая не всегда согласуется с представлениями об элегантности и к тому же замедляет текущую работу. Поэтому от программиста требуется определенная самодисциплина в разработке и оформлении программы. Есть и ряд других специфических требований, относящихся к личностным и интеллектуальным качествам, которые программист должен проявлять в своей профессиональной деятельности, даже если он не способен на это в своей повседневной жизни. Это, например, объективная требовательность к себе. Слова «у меня все правильно, но программа почему-то не работает» безошибочно выдают новичка. Программисту необходимо упорство в доведении работы до конечного результата. Он должен проявлять спокойствие и одновременно непримиримость по отношению к собственным ошибкам, должен всегда находить первопричину ошибки, а не довольствоваться случайным исчезновением ее внешних проявлений. В постановке задачи он должен уметь обобщать существующие потребности и учитывать будущие, не скатываясь однако к беспорядочному накоплению всяких дополнительных возможностей и трезво оценивая собственные ресурсы (ср. «эффект второй системы» по Ф. Бруксу). Он должен уметь становиться на место пользователя своей программы, понимать его потребности, не идя, однако у него на поводу в выборе форм их удовлетворения и помогая ему лучше понять собственные проблемы. Для него важно умение видеть задачу одновременно на нескольких уровнях детализации. Все эти и многие другие требования образуют понятие профессионализма, культуры программирования. (Вопрос студента: культура программирования – это когда пишут строчки с разным отступом от края?)

Если же говорить об использовании в программировании количественных оценок времени и памяти только из-за того, что не видно других оценок, то стоит заметить, что сам поиск числовых оценок – это проблема не программиста, а его менеджера. Программист, конечно, знает, сколько места занимает его программа (особенно, если не хватает памяти), но он так же хорошо понимает, что оценивать его работу в байтах – это все равно, что планировать выпуск станков в тоннах. (Есть, хотя еще не получил широкого признания, количественный критерий, осмысленный для программиста. Он, в сущности, тот же, что и называемый Г.Р. Громовым критерий для микросхем – количество наружных выводов; для программы – это сложность ее сопряжения с внешним окружением, в частности, количество и типы параметров, используемых внешних файлов и т.п.) Попытки построить особую науку о программировании на базе численных оценок кажутся мне несерьезными: если измерение и установление численных закономерностей сыграли решающую роль в формировании современной физики или химии, то это еще не значит, что тот же путь будет успешным для программирования. В мире есть много ценностей, не выражающихся в числах.

И наконец, о «большой науке программирования» вместе с ее утопией автоматического синтеза программ. Не стоит отождествлять эту науку с «соответствующими научными школами, которые, достигнув достаточно высокого уровня в социальной структуре науки об ЭВМ, и определяют в настоящее время научный облик большой науки программирования», как написано в книге Г.Р. Громова, с.161. Не говорит этого и А.П. Ершов, на статью которого ссылается здесь Г.Р. Громов.

Наука программирования развивалась вместе с практическим программированием, систематизируя его опыт и исследуя подсказанные им теоретические модели. Далеко не весь собранный опыт может быть выражен в научной форме: он часто передается в виде афоризмов, притч, анекдотов, заповедей, рассказов о конкретных случаях. Такой характер носят и многие переводные книги по разработке программного обеспечения (как мне показалось, для американской литературы вообще характерна подобная форма передачи жизненного опыта; вспомним давнюю книгу Д. Карнеги «Как приобретать друзей и влиять на людей»). Это знания, находящиеся, если можно так сказать, на преднаучной стадии.

Но многое собрано и в более четкой форме. Это большой запас разнообразных инженерных решений относительно организации данных и их представления в машине, эффективные алгоритмы для распространенных задач их обработки, согласованные с этими способами представления, опыт и инструменты проектирования универсальных и специализированных языков программирования и машинной реализации этих языков. Для тех, кто сомневается в прогрессе нашей науки, можно напомнить, что разработка трансляторов, которая в конце 50-х годов представляла собой уникальное научное усилие, теперь стала делом рядовой дипломной работы. Особенно важной частью накопленного опыта построения языков является выделение ряда форм членения программ на осмысленные части и описания сопряжений между ними. Это процедуры и передача параметров, элементарные операции структурного программирования, квазипараллельное выполнение и сопрограммы, структурные переходы и задание реакций на ошибки, пакеты процедур и абстрактные типы данных, логические спецификации программ и правила их преобразования, средства трансформации программ и макрогенерация, фреймы и синтез программ по вычислительным моделям, структуры баз данных и языки для обращения к ним, системы поддержки больших программных разработок, «окна» и объектно-ориентированная машинная графи- ка, возвраты, демоны и прочие структуры управления для систем искусственного интеллекта, системы продукций, средства межпроцессорной связи и сетевые протоколы, семафоры и «рандеву», взаимная защита программ и пользователей и многое другое.

Все эти средства направлены не на эффективность реализации создаваемых программ, а на саму постановку задачи, на ее приближение к пользователю программы. Многие из этих средств в момент создания могли рассматриваться просто как удачные инженерные и научные находки, однако их устойчивость, повторение с несущественными различиями во многих системах дают основание думать, что за этим стоит нечто большее, а именно, какие-то реально существующие особенности организации человеческого знания и деятельности. Фактически именно они лежат в основе предмета науки программирования, и именно их мы постепенно познаем, обобщая опыт удачных инженерных решений, касающихся способов описания задачи. Модульность в программировании возникла не в подражание проектированию электронных схем, а как отражение модульности человеческого знания. Ничего немодульного мы просто не сможем придумать, а если мы даже преобразуем модульную программу в монолитную, то для нас все равно будет понятным ее исходное, модульное задание; исходная модульность программы может быть лишь затемнена ее неудачным представлением. Поэтому модуль для программирования в фундаментальном значении этого понятия нельзя отождествлять с частными формами модульности, определяемыми в конкретных системах программирования. Полное содержание понятия модуля в программировании пока не раскрыто.

Исторически наука программирования развивалась в первую очередь как математическая дисциплина и применялась в первую очередь к математическим областям знания. Это обеспечило программирование мощным математическим аппаратом, особенно полезным для описания структур объектов и построения алгоритмов решения на ЭВМ многих математических задач. Мы научились описывать как математические объекты не только обрабатываемые данные, но и сами программы, их преобразования, в том числе процесс трансляции. В реальных программистских разработках, как это естественно для любой прикладной области, строгий математический аппарат не употребляется в чистом виде, а иногда даже и не заметен снаружи. Но он образует прочный скелет используемых методов и к нему приходится вновь обращаться, как только покидаешь привычную рабочую среду.

Но с другой стороны – и это естественно для математической науки – математический аппарат стал развиваться и независимо от внешних задач, создавать собственные задачи и теории, которые могли и не иметь отношения к практическим потребностям. Так, теория формальных языков, первоначально давшая фундаментальные результаты, лежащие в основе как техники трансляции языков программирования, так и современных лингвистических теорий, исчерпала свой потенциал, уйдя в разнообразные обобщения и варианты, не отражающие ни потребностей программирования (разрабатывая новые языки, мы можем сознательно избегать синтаксических сложностей), ни тех явлений естественного языка, которые не укладываются в прежние формальные модели. Встречаются и другие работы, лишь по форме связанные с актуальными направлениями практического программирования.

Техника логического аннотирования и верификации программ вместе со своим теоретическим аппаратом возникла на основе применений программирования к математическим задачам, в которых только и имеет смысл понятие математического доказательства (не станем же мы всерьез доказывать о программе начисления премий, что она отвечает принципу социальной справедливости). Кроме того, предположения о практическом применении этой техники связаны с созданием аппарата поиска логического вывода, который бы позволял строить вывод по записи проверяемого утверждения. Удовлетворительных общих средств для решения такой задачи не предвидится. Если же, как иногда делается, расширить постановку задачи от верификации до синтеза программы по логической спецификации, то мы по существу потребуем системы, способной автоматически решать чуть ли не любую математическую задачу. Ясно, что рассчитывать на применение этой техники в такой форме несерьезно, а ссылки на успехи таких работ на материале небольших примеров ничем не лучше восторгов новичка, впервые выдавшего на свой терминал слова «Здравствуй, Вася!» и решившего, что теперь он знает все программирование.

Роль теории и методов логической верификации и синтеза программ совсем иная. Научное значение этой теории в том, что она раскрывает соотношение между двумя фундаментальными формами знания: описательной и процедурной. (Но она не исчерпывает их взаимоотношения.) Прикладное ее значение (пока почти не реализованное) связано с тем, что и логические рассуждения, и элементарные операторы присутствуют почти в каждом шаге реально создаваемых программ, хотя программа в целом может быть основана на знаниях другого рода. И автоматизация подробного развертывания таких элементарных шагов на основе внешних спецификаций, и трансформация такой программы в процессе автоматизированной сборки из модулей потребуют использования всего запаса средств логической верификации и синтеза в сочетании со средствами трансформации. Мощные средства сборки и генерации программ обеспечат многократную используемость модулей, избавят от необходимости полного переписывания программ из-за частных изменений требований к ним или из-за переноса в новое окружение. В этой перспективе нет ничего утопического, хотя еще предстоит большая работа как по выделению необходимых для этого форм модулей, так и по развитию необходимого математического аппарата.

Возражения Г.Р. Громова, заявляющего о бесполезности автоматизации программирования в связи с тем, что оно, по новейшим данным, ответственно лишь за ничтожную часть затрат на разработку и сопровождение, неверны по двум причинам. Во-первых, он причисляет к программированию только кодирование программы на конкретном языке; выделение этого этапа несколько искусственно и связано, видимо, с необходимостью разделения труда между более квалифицированными работниками, разрабатывающими общую схему, представление информации и спецификации отдельных модулей, и менее квалифицированными кодировщиками. Разработка общей структуры программы тоже входит в сферу программирования, а в случае ее полной или частичной автоматизации будут сняты количественные ограничения, приводящие сегодня к отделению этой работы от кодирования. Кроме того, сейчас разрабатывается много средств, направленных специально на поддержку разработки структуры больших программных систем и автоматизацию многих этапов такой разработки. Во-вторых, даже при нынешнем соотношении между затратами на разные этапы затраты на кодирование и отладку на его уровне достаточно велики, и это обстоятельство удерживает руководителей разработки от многократного повторения этого этапа. Если бы этот этап сейчас уже был автоматизирован, можно было бы в пределах одной разработки быстро испытать много вариантов решений, принимаемых на более высоких уровнях, и выбрать лучший.

Неправ Г.Р. Громов и в том, что распространение персональных ЭВМ обесценивает прежние достижения программирования. В отношении техники программирования в узком смысле слова здесь как раз ничего не меняется, потому что по архитектуре новые машины весьма традиционны; более того, вновь вступают в силу забытые было методы экономии памяти и тактов. То же можно сказать и о программировании для микропроцессоров, встроенных в технические средства, где относительно новыми являются лишь требования параллелизма и реального времени. Изменения происходят в совсем другом: меняется круг задач и круг пользователей, меняются приоритеты критериев, основанных на экономических оценках, и типовые решения, основанные на таких приоритетах, резко увеличивается потребность в производстве программного обеспечения. Это может привести к пересмотру организационных и некоторых инженерных решений, но не основ науки. Кстати, аналогичный «скандал в благородном семействе» назревает и в разработке языков программирования, где потребности сместились с обеспечения разработки полнокомплектных программ достаточно большого размера к созданию достаточно малых модулей, где интерфейс по размеру едва ли не больше тела модуля и потому совсем иной характер принимают требования к синтаксису. Успех ряда совсем небольших по определению языков на фоне таких гигантов, как Ада, возможно, связан с этим обстоятельством. Это может изменить традиции разработки и использования языков, обесценить какие-либо конкретные разработки, но, конечно, не разрушит основ науки программирования, которой, по большому счету, надлежит даже предвидеть такие явления.

Можно еще заметить, что с распространением персональных ЭВМ не утрачивает силу и старая мечта об общественных вычислительных системах, к которым будут подключаться индивидуальные терминалы. Ведь рано или поздно встанет вопрос о подключении персональных машин к большим информационным системам, так что разница будет лишь в том, что связь с большой системой потребуется не при каждом нажатии кнопки на терминале.

Так что рано списывать «большую науку программирования» в утиль или выставлять ее представителей как людей, тормозящих технический прогресс. Встречаются высказывания некоторых очень заслуженных теоретиков, исключающие из науки все, кроме их узкой области, но на науку нельзя возлагать ответственность за это. И конечно, программирование – это не чисто математическая наука; даже пользуясь развитым математическим аппаратом, она применяет иные критерии ценности результатов. Она объединяет разнообразные аспекты рассмотрения своих объектов: от фундаментально-научных и инженерных до когнитивно-лингвистических, психологических и социальных. Это относится как к информатике в целом, так и к программированию – ее части, рассматривающей информационную продукцию в отличие от материальной.

Я готов вместе с Г.Р. Громовым пожелать доброго пути энтузиастам, которые, вооружившись вычислительной машиной, смело отправляются в поиск по научной целине. Только зачем же босиком? (Простите, Бейсиком.) Мы вполне можем их обуть. А может быть, и вездеход сообразим... 

Материалы международной конференции SORUCOM 2011 (12–16 сентября 2011 года)
Помещена в музей с разрешения автора 6 января 2014