Изменить стиль страницы

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

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

Объединенные среды программирования. Считается, что Unix и Interlisp, первые широко распространенные интегрированные среды программирования, повысили производительность в несколько раз. Почему?

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

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

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

Надежды на серебро

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

Ada и другие достижения языков высокого уровня. Одним из наиболее рекламируемых достижений последнего времени является язык программирования Ada — язык высокого уровня общего назначения 80-х годов. Ada действительно не только отражает эволюционное развитие концепций языков, но и воплощает черты, поддерживающие современные идеи проектирования и модульности. Возможно, большим достижением является не язык Ada, а философия Ada как философия модульности, абстрактных типов данных, иерархического структурирования. Ada, пожалуй перегружен возможностями, будучи естественным продуктом процесса, породившего требования, положенные в основу его разработки. Это не смертельно, поскольку подмножества рабочих словарей могут решить проблему изучения, а прогресс электроники даст нам дешевые миллионы операций в секунду, решающие проблему компиляции. Развитие структурированности программных систем — это очень хорошее применение для денег, которые мы тратим на приобретение все больших вычислительных мощностей. Операционные системы, громко осуждавшиеся в 60-х годах за дороговизну памяти и вычислений, оказались хорошим способом применения быстродействия и дешевой памяти, полученных в результате быстрого развития аппаратных средств.

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

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

Объектно-ориентированное программирование. Многие, изучающие искусство программирования, связывают с объектно-ориентированным программированием больше надежд, чем с любыми другими современными техническими увлечениями. [3] Я принадлежу к их числу. Марк Шерман (Mark Sherman) из Дартмута замечает, что следует проводить отличие между двумя разными идеями, фигурирующими под этим названием: абстрактных типов данных и иерархических типов, называемых также классами. Понятие абстрактного типа данных состоит в том, что тип объекта определяется именем, множеством допустимых значений и множеством допустимых операций, а не организацией хранения, которая должна быть скрыта. Примерами являются пакеты Ada (с защищенными типами) и модули в языке Modula.

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

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

И все же такие достижения могут не более чем устранить второстепенные трудности при выражении проекта. Существенна сложность самого проекта, на что решение таких задач никак не может повлиять. Добиться выигрыша на порядок величин с помощью объектно-ориентированного программирования можно лишь в том случае, если остающаяся сегодня в нашем языке программирования необязательная работа по спецификации типов сама по себе ответственна за 9/10 усилий, затрачиваемых на проектирование программного продукта. В этом я не сомневаюсь.

Искусственный интеллект. Многие ожидают, что успехи в области искусственного интеллекта позволят осуществить революционный переворот, который принесет рост производительности разработки программного обеспечения и его качества на порядки величин. [4] Я этого не жду. Чтобы увидеть, почему, разберем, что понимается под «искусственным интеллектом», а затем посмотрим, какие возможны применения.

Парнас внес ясность в терминологический хаос:

Сегодня в ходу два совершенно разных определения ИИ. ИИ-1: использование компьютеров для решения задач, которые раньше могли быть решены только с помощью человеческого интеллекта. ИИ-2: использование специальных приемов программирования, известных как эвристическое, или основанное на правилах, программирование. При таком подходе изучают действия экспертов, чтобы определить, какими эвристиками и практическим правилами они пользуются при решении задач… Программа корректируется для решения задач так, как, по-видимому, ее решает человек.

У первого определения скользкий смысл… Кое-что укладывается сегодня в определение ИИ-1, но как только мы видим работу программы и понимаем задачу, мы уже не думаем о ней, как о ИИ… К несчастью, я не вижу ядра методов, которые уникальны в этой области… По большей части методы проблемно-ориентированны, и для их переноса требуются известные абстракция и творчество. [5]

Я полностью согласен с этой критикой. Приемы, используемые для распознавания речи, выказывают мало сходства с методами распознавания изображений, при этом в экспертных системах используются методы, отличные от тех и других. Я затрудняюсь сказать, к примеру, какое влияние распознавание изображений может оказать на методы программирования. То же самое справедливо в отношении распознавания речи. При разработке программ трудно решить, что именно сказать, а не собственно сказать. Никакое облегчение выражения не может дать больше, чем незначительные выгоды.