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

В статье Алексея Кулаичева я готова согласиться с основным выводом (программные продукты достигли того уровня сложности, при котором они становятся полноправными объектами научного исследования), хотя аргументация представляется мне во многом несостоятельной.

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

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

С другой стороны, проблема, возможно, глубже, чем представляется автору, который видит основной источник бед в недобросовестности разработчиков и составителей документации: не исключено, что программы уже перешагнули тот "порог сложности", за которым полный контроль над ними неосуществим. Что же касается ООП, то оно дает разработчику принципиальную возможность не контролировать программу в целом. Он моделирует программный продукт с заданными свойствами, описывая отдельные объекты и способы взаимодействия между ними, а как будет работать эта модель, заранее, строго говоря, неизвестно. В результате может оказаться, что даже разработчик, помнящий наизусть каждую строчку исходного кода, не сумеет ответить на вопрос: "А почему ваша программа в такой-то ситуации делает то-то и то-то?"

Видимо, автор не знал о существовании книги Мэтта Питрека "Внутренний мир Windows", русский перевод которой вышел в 1995 г. в киевском издательстве "Диасофт". Питрек, решив, что ему необходимо самостоятельно разобраться с Windows, подошел к проблеме прямо: деассемблировал файлы и стал читать код. Не думаю, что многим это под силу, но в науке нет легких путей...

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

Во-вторых, автор, видимо, в значительной степени сам находится под влиянием идеологии "тычка и щелчка". Что мы, все неграмотные? Неужели о способе создания стилей в текстовом редакторе нельзя рассказать в письме на простом русском (английском, японском, турецком) языке и послать это письмо коллеге (благо есть электронная почта, а нет - можно и обычной)? И почему он говорит об универсальной системе записи макрокоманд (в смысле запоминания последовательности действий пользователя), а не о независимом от платформы языке программирования вроде Java? Тут нелишне заметить, что интерфейс командной строки, где пользователь должен словами (правда, на специализированном языке) объяснять машине, чего он хочет, имеет, конечно, массу недостатков, но вот утомительное однообразие ему не свойственно. Я далека от того, чтобы пропагандировать возвращение к командной строке - оно вряд ли реально, - хочу лишь призвать всех участников будущих дискуссий мыслить как можно шире и свободнее, стараясь выйти за стандартные рамки.

545