В рамках обучения студентов, возникает момент, когда нужно перейти от искусственных задач к реальным. В этот самый момент происходит определённый слом в понимании программирования, цикла жизни программы (один из).
Раньше мне было довольно сложно понять причины этого, различия: где уютная синтетическая задача, а где суровая "реальная". На днях в одном из чатов подсказали очень интересные формулировки двух парадигм программирования. Да, это очередная "ненужная" классификация, но мне она помогла. Возможно, поможет ещё кому-нибудь. Тем более, что в русскоязычных источниках такой классификации не нашёл. Итак,
Парадигма автомобиля (Car paradigm) – программирование в стиле "из точки А в точку Б". Объекты (в широком смысле) используются единожды, мы просто движемся по трассе, не особо заботясь об окружающей среде: возвращаться не придётся – да гори оно огнём.
Эта парадигма подходит для программирования простеньких скриптов, у которых одна задача, которую они делают и умирают, закрывая за собой все забытые дескрипторы, освобождая утёкшую память и т.д.
Примеры:
- скрипт по перегонке из cp1251 в utf8;
- программа-установщик;
- cgi/php-страничка
– все те программы, рождённые, чтобы умереть.
И это прекрасно – чем быстрее программа завершится, тем меньше ресурсов она съест, меньше ошибок наделает и т.д. Однако, реальность нас ведёт к сервисам, демонам и fastcgi-подобным скриптам. Отсюда мы имеем и вторую парадигму:
Парадигма часов (Clock paradigm) – программа работает постоянно, обрабатывая запрос за запросом, отдавая ответ за ответом. Здесь уже нельзя "сжигать за собой мосты", нужно думать о чистоте переменных, об уменьшение side-эффектов.
Здесь те самые не освобождённые ресурсы приведут к падению программы от рук Out-Of-Memory Killer-а. А те самые незакрытые дескрипторы вскоре закончатся. А уж сколько радости принесут глобальные переменные...
Примеры:
- сервер видео/аудио - стримминга;
- интерактивная игра;
- HTTP-серверы для работы, а не разработки.
Именно переход от попустительства в плане ресурсов к заботе о чистоте окружения и может быть одним из качественных показателей роста программиста.