О «кризисе» в программном обеспечении. Часть 1.

К концу 70-х годов «программистский мир» был охвачен беспокойством: со страниц книг и журналов, газет и отчетов о конференциях не сходило слово «кризис» — кризис программного обеспечения. Если полагать, что положение в программировании с тех пор стало заметно более стабильным, то тем более поучительно разобраться, насколько преодолены те противоречия, которые указывались как признаки кризиса. К числу наиболее серьезных из них относились следующие.

Вверх по лестнице, ведущей вниз
  1. Аппаратура становилась дешевле и надежнее, программирование — дороже, а надежность программного обеспечения никого не удовлетворяла.
  2. Ожидаемое значительное упрощение программирования не было достигнуто — фактически оно неуклонно становилось все сложнее. Автоматизация программирования не освобождала программиста от различных технических ограничений и утомительных рутинных частностей, а с введением новых средств их автоматизации программист все больше погружался в массу технических деталей и предписаний, не имеющих прямого отношения к решаемой задаче.
  3. Запасы программ увеличивались — их общедоступность оставалась ограниченной, а поэтому часто проще было сделать самому, чем суметь найти и воспользоваться готовым.
  4. Общесистемное программное обеспечение создавалось с целью упрощения решения прикладных задач, однако стало типичным вовлечение проблемного специалиста в общесистемную проблематику.
    Операционные системы потребляли столько вычислительных ресурсов для самоподдержания, что вычислительная система «пробуксовывала», а в целом вела себя в соответствии с законами Паркинсона.
  5. Развитие элементной базы могло обеспечить высокое быстродействие отдельных узлов вычислительной аппаратуры — производительность систем обработки данных в целом была не адекватна этим возможностям.
  6. Введение международных и национальных стандартов на промышленные языки программирования, рост количества и качества новых машинно-независимых языков (рис. 1.1) не сняли проблем несовместимости и нетранспортабельности программ. Не известны хотя бы две абсолютно одинаковые версии какого-либо одного и того же языка, реализуемого разными трансляторами. Ни один из известных конверторов не решал полностью задачу автоматического преобразования программ по отношению к таким версиям языков.
  7. Ожидалось значительное повышение уровня интеллектуальности вычислительных систем, тем не менее программы при повышенных требованиях надежности писались в машинном коде. Машинные языки при этом оставались низкоуровневыми, эклектичными и неудобными ни для ручного, ни для автоматического программирования.
  8. Потенциальные возможности программиста локально не ограничены: нетрудно написать и отладить одну подпрограмму, затем другую и т. д., а для реализации собственных идей достаточно написать вполне обозримое количество подпрограмм. Но в этом «и т.д.» и заключены, в сущности, проблемы технологии производства больших программ — слишком многие проекты, надежно обеспеченные человеческими и машинными ресурсами, терпели провал.
  9. Теоретическое программирование слишком отставало от практики. Поэтому, в частности, экологические ниши, подходящие для языков АЛГОЛ-60, АЛГОЛ-68 и даже АДА, оказывались прочно занятыми языками ФОРТРАН, макроассемблер и ПЛ/1. В связи с этим поучителен следующий факт. Венской научно-исследовательской лабораторией фирмы «IBM» в результате многолетних усилий было выработано строгое описание ПЛ/1 с формализованным описанием семантики языка в терминах абстрактной интерпретирующей машины, и хотя это описание было принято в качестве американского национального стандарта, а затем и стандарта ИСО (Международной организацией по стандартизации), на практику программирования оно уже не успел оказать заметного влияния — версии ПЛ/1, обеспеченные трансляторами той же IBM, распространились на столько широко, что переход на новый стандарт язык потерял всякий смысл.