To put it quite bluntly: as long as there were no machines, programming was no
problem at all; when we had a few weak computers, programming became a mild problem,
and now we have gigantic computers, programming has become an equally gigantic
problem.
вольный перевод на русский
Скажу прямо: пока машин не было, программирование не было проблемой вовсе; когда появились слабые компьютеры, программирование стало умеренной проблемой; теперь, когда у нас гигантские компьютеры, программирование стало столь же гигантской проблемой.
Каждая парадигма программирования рождалась как ответ на кризис роста: сложность программ обгоняла инструменты, которыми их писали. Чтобы понять, зачем нужно ООП, стоит пройти этот путь с самого начала.
Первая программа появилась раньше компьютера
1843 около 25 операций
Первая программа была написана задолго до появления компьютера – это был «скрипт» для аналитической машины Бэббиджа, вычислявший числа Бернулли. Написала его английский математик Ада Лавлейс; в её честь позже назвали язык Ada.
Вся программа умещалась в одну таблицу – порядка двух десятков операций. Её можно было целиком охватить взглядом и проверить в уме, поэтому вопроса «как это устроено» просто не существовало.
Машинные коды и ассемблер
1940-е – 1950-е десятки и сотни инструкций
Появляются первые компьютеры, а с ними – первые цифровые программы в машинных кодах. Следом приходит ассемблер, который транслирует человекочитаемые команды в команды процессора.
Это первые императивные языки: программа – это последовательность команд, выполняемых одна за другой. Об организации кода тогда никто не думал – напиши так, чтобы работало, и забыли. Основными программистами были математики, а их задачи редко выходили за пределы одной мудрёной формулы.
Размер программы – десятки, реже сотни инструкций. Столько человек ещё держит в голове целиком, так что инструмент для организации кода не нужен: инструментом был сам автор.
Процедуры: первая попытка навести порядок
1957 – 1972 тысячи и десятки тысяч строк
Компьютеры становятся мощнее, задачи – абстрактнее, и появляется потребность выделять подпрограммы средствами самого языка. Так возникают первые высокоуровневые языки – Фортран, Кобол, Бейсик, а позже Си, где разбиение программы на процедуры стало центральной идеей.
Тогда же Дейкстра пишет знаменитое эссе «Goto considered harmful» (1968). Индустрия впервые всерьёз задумалась: код должен быть не только рабочим, но и понятным.
Причина простая: программа переросла одного человека. Тысячи строк в голове уже не помещаются, и процедура – первый ответ на вопрос «как читать код, который не читал целиком».
Кризис программного обеспечения
1968 – 1970-е сотни тысяч и миллионы строк
К 60–70-м годам небольшие алгебраические скрипты превращаются в огромные вереницы кода. Количество процедур растёт в геометрической прогрессии, а пара математиков-энтузиастов сменяется штатом программистов, каждый из которых норовит изменить чужую подпрограмму.
Появляются программные продукты нового масштаба – операционные системы. У IBM OS/360 к концу 60-х около миллиона строк и тысячи человеко-лет работы; такую систему не то что написать – прочитать в одиночку нельзя. Разница с программой Лавлейс – примерно в сорок тысяч раз, а инструменты остались теми же процедурами.
Это время в индустрии так и назвали – кризис программного обеспечения. Виноватого не было: процедуры работали как задумано, просто их стало слишком много. Значит, не хватало самого инструмента – способа резать программу на куски, которые держишь в голове по одному.
По какой линии резать, выясняли следующие двадцать лет. Дальше в модуле – что ответили Simula и Smalltalk.