Когда деревья были большими...

В последнее время приходится проводить много профессиональных интервью с программистами. Так вот, я заметил, что многих ставят в тупик вопросы об основных постулатах ООП – наследовании, инкапсуляции, полиморфизме. Складывается впечатление что раньше (несколько лет назад) с этими вещами у программистов были дела получше. Я задумался о причинах такой деградации, и вот какое объяснение пришло мне в голову.
Во всем виновато повсеместное распространение объектных языков и объектного подхода в программировании.
Да – да, именно так. Много лет назад, когда деревья были большими, компьютеры были тоже нехилых размеров. До сих пор не забуду, как на кафедру вычислительной техники доставили новый компьютер... С железнодорожной станции целый день шли Камазы груженные аппаратурой. Нашей группе досталась разгрузка ЦПУ, когда этот, с позволения сказать, процессор освободили от тары и взгромоздили подъемным краном на крыльцо учебного корпуса, мы все почувствовали благоговение перед мощью вычислительной техники. На остатках тары мы прочитали: «Масса брутто 2100 кг. Мaсса нетто 1800 кг.». Перемещали циклопический процессор по коридорам кафедры двадцать человек, опутав его веревками и установив на лист войлока толщиной полтора сантиметра. Подобно древним Египтянам мы воздвигали алтарь нового бога – ЕС 1036. С появлением этой машины, мы могли пользоваться терминалами, раньше приходилось вводить тексты программ и исходные данные на перфокартах.
Впрочем я отвлекся, пустившись в исторический опус, размеры машины тут не причем. В те времена мы изучали программирование на таких языках, как FORTRAN, ALGOL 60, PL1. Только - только появлялись смешные машинки, размером с современный компьютерный стол, с веселым названием ДВК и зашитым в ПЗУ Бейсиком, к которому все мы испытывали искреннее презрение. Тем не менее, все мы твердо усвоили, что программа состоит из двух частей: данных и инструкций по обработке этих данных. Инструкции могут объединяться в подпрограммы процедуры и функции, те с свою очередь могут составлять библиотеки. Объектный подход в корне ломал все. Оказывается можно объединить данные и процедуры по их обработке в одном объекте. Объект это не данные и это не модуль это конгломерат того и другого. Все это необходимо было осознать, пропустить через себя. Области видимости данных, отличные от локальных и глобальных, казались невероятным усовершенствованием. Далее - наследование. Это было что-то фантастическое. Впрочем, наследование, это самая естественная и понятная из парадигм ООП. Полиморфизм - это казалось шаманством чистой воды. Многим было легче понять, как работает его реализация на таблицах виртуальных методов, чем сам смысл этого явления. В общем, для того, что бы научиться объектному подходу, нам приходилось пропускать через себя все его основы.
Тем, кто сегодня начинает программировать, часто так же трудно представить себе, что функция может быть объявлена не в классе, как нам было трудно понять, как к структуре данных можно привязать процедуры и функции. Сейчас любой учебник начинается с описания того, как с помощью визарда создать обработчик нажатия кнопки на форме. И многие долгие годы пребывают в уверенности, что этот обработчик принадлежит классу кнопки а не формы! Умные IDE автоматически подставляют слово override в объявление метода, и немногие могут объяснить для чего оно нужно.
Объектные парадигмы приходят как сами собой разумеющиеся, но мало кто может их с толком использовать. Человек жалуется в форуме: «Я сделал у класса конструктор приватным, а теперь не могу создать его экземпляр, используя имя класса и технологию отражения». Хочется спросить: - «В своем ли ты уме, парень? Ты отрубил голову подозреваемому, и теперь жалуешься на то, что он молчит на допросе». Многие борются с виртуальными методами, пытаясь заставить их работать как не виртуальные...
Может стоит начинать преподавать программирование на каком ни будь АЛГОЛе, PL1 или голом С, что бы потом у людей формировалось истинное понимание сути ООП?