Аннотация: О прогрессе в современном программировании. Читайте, если вы разбираетесь в программистских терминах. Обычному читателю будет непонятно.
Прогресс в программировании.
Сейчас очень модным стало функциональное программирование, ранее последним писком моды было ООП, ещё раньше программисты балдели от SQL и структурного программирования. Далее, в глубь времен, заходить не вижу смысла. Каждое следующее поколение инструментов вызывало чувства сродни религиозного экстаза. Говорить что-то против считалось и считается скудоумием, ретроградством, старческим брюзжанием. Все итерации вынуждали программиста заново переучиваться превращая профессионала на довольно приличное время в неумеху. В начале времен новое поколение давало существенное преимущество по сравнению с предыдущим:
Первое поколение.
1. Замена основанных на переборе СУБД на SQL позволила перейти от изолированных мельчайших групп к системам масштаба предприятия и более. Поистине революция.
2. Структрурное программирование позволило резко расширить масштаб более менее управлямых программ. Оригинальные Кобол, Фортран и другие доструктурные языки быстро превращали программу в нечитаемое месиво. На них можно было писать весьма изощренные, но относительно короткие программы. Здесь переход был не столь резкий, но структурное программирование закономерно вытеснило предшественников. На короткой дистанции оно было ничем не хуже, а на средних и больших программах преимущество оказывалось подавляющим.
Второе поколение.
1. Объектно-ориентированное программирование. Рекламировалось своими создателями как "золотая пуля" при создании больших и сверхбольших программ. Ещё в те времена было очевидно, что ООП расходует ресурсы компьютера заметно сильнее предшественника, а объем кода становится больше. Предполагалось, что основные структурные языки станут подмножеством объектно-ориентированных и это позволит безболезненно совершить переход.
На практике дополненные ООП языки стали плохо управляемыми мастодонтами унаследовавшими все проблемы предшественников и добавившими своих. Самый известный язык такого рода - C++. Его объёмы спецификаций столь необозримы, что 90% программистов на нем знают лишь подмножество языка. Хотя на C++ написано много хороших проектов, но не меньшее количество осталось на структурном С. Windows, Linux, много малых, больших, гигантских проектов хорошо чувствует себя на этом языке и никуда не собирается меняться. Примерно такая же ситуация складывается с другими языками надстройками.
С целью убрать недостатки языков с ООП надстройками были созданы чистые ООП языки (они были и ранее, но автору интересны лишь самые ходовые. Язык, собравший тусовку около тысячи другой поклонников, в мировом масштабе заметен как песчинка на пляже). Создатели Java (самый распространённый язык программирования в мире) решительно выкинули массу возможностей С++, отказались от совместимости с С. Небольшой, логичный и относительно простой, на протяжении 20 лет язык завоевал симпатии в мировом масштабе. Пожалуй, это пик развития ООП. Другие ООП языки либо существенно меньше по доле рынка, либо страдают ожирением.
Тем не менее Java с компанией других ООП языков оказалась не в силах вытеснить структурных предшественников как те сделали со своими предтечами. На маленьких программах в ООП мало пользы, в средних лишь часть задач выгодно решать в объектном стиле. Казалось бы, ООП должно отыграться на больших проектах. Но, как было показано выше, это далеко не факт. Люди, съевшие собаку на структурном программировании, успешно работают спустя 30-40 лет после массовой обработки программистов в ООП стиле. Работают не хуже объектников, которые тоже успели съесть собаку на своем подходе.
Более существенно, что ООП подход позволил создать языки зажимающие программиста в четкие рамки. Это не сняло проблему быдлокодеров, но позволило сильно сократить количество запутанных программ. Пожалуй, это главное достижение ООП подхода. Есть задачи, где ООП прекрасно обслуживает предметную область, а есть задачи где он мешает. И тех и других много.
Вывод - несмотря на непрерывную пропаганду, море программ на ООП подход так и не стал "золотой пулей". На малых программах польза от методологии отсутствует. На средних/больших мнения могут быть разные.
Третье поколение.
Функциональное программирование возникло не позднее структурного. Ему не менее 60 лет. Примерно до 2010 года оно оставалось уделом немногочисленных поклонников, либо нишевым решением. Например, система проектирования AutoCAD ещё со времен MS-DOS использовала функциональный язык LISP. Erlang отлично подошел для систем обслуживания звонков. Однако, в течение почти всей жизни функционалки она была известна подавляющему большинству лишь по названию. Во многих университетах она изучалась и быстро забывалась после. Почему вдруг такое пренебрежение и вдруг стремительный расцвет?
1. Функциональные языки не набрали массу. Когда у нас то нет нужной библиотеки, то нет реализации на нужной платформе - это способно придушить любой язык. Сейчас ситуация разрешается.
2. Совместимость. Из-за порядка вычислений, ленивости, модуль делается непредсказуемым со стороны не-функциональных языков.
3. Стиль программирования резко отличен от более простых императивных языков. Переучивание достигается большой кровью и временем.
4. Мало документации - сейчас поправимо.
Поклонники функциональных программ упирают на легкость поддержки, компактность кода. Функциональные элементы вносятся в языки других парадигм. В них они находят горячих поклонников, но с точки зрения старой школы это не более чем новая запись старых конструкций. Чуть более компактная. Синтаксический сахар можно безболезненно проигнорировать. Полностью функциональный стиль требует ломки. Человек лучше понимает последовательность действий приводящих к результатам нежели математические вычисления. Действительность показывает, что выучить с нуля функциональщика труднее чем обычного хорошего программиста. Не факт, что он останется и далее поклонником этой парадигмы.
Т.е. главный недостаток функциональных языков - это сложность обучения. В отличие от предыдущего лидера функциональное программирование полностью заменяет стиль мышления. Поэтому озеро функциональных проектов по сей день выглядит жалко по сравнению с океанами ООП и морями структурного подхода. Нет сомнений, что постоянное превознесение подхода принесет ему инфраструктуру, финансы, поклонников. Однако, величия ООП ему не достичь. Функциональные языки также имеют свою нишу, где они наиболее подходящи. Но подавляющего преимущества они никогда не обеспечивали, не обеспечат и сейчас.
Популярность функциональных языков выросла после того, как остановилось действие закона Мура. Если ранее 2-3 лет хватало для полного устаревания одноядерного процессора, то теперь можно работать на машине десятилетней давности без особого напряжения. Даже игры не спасают производителей железа от падения продаж. Выход был найден в распараллеливании. Процессы стали многоядерными. Проблема лишь в том, что хорошо распараллеливаются лишь задачи на сервере. Некоторый эффект достигается от разнесения по ядрам процессов ОС и прикладных программ. Но 2-3 ядер для этого достаточно. 6-8 ядерные персональные монстры крайне редко могут использовать все свои возможности.
У традиционных языков вроде Java либо сильно запутанная модель многопоточности, либо её вообще не было в общем виде (С/С++). Многопоточность создает трудноуловимые, внезапные ошибки, когда нити меняют одни и те же данные. Блокировки снижают производительность и могут вызвать зависание. Вот тут неизменяемость данных, чистота функций в функционалке наконец-то перевесила простоту императивных языков. Функционалкой заинтересовались сильные мира сего.
В коммерческом программировании работа с многопоточностью эпизодична. Автору за 20 лет работы встретились лишь программы где она убрана "под капот". Программисту иметь с ней дело просто не нужно. Следовательно, функциональное программирование в большой степени становится балластом.
С точки зрения предприятия, нет ни малейшего смысла резко менять методологию неся неизбежные потери в бизнесе. Подавляющее большинство контор работает на том инструменте, что выбрали изначально. Лишь постепенно в них появляются вскормленные мощной пропагандой ИТ фирм ростки нового (попытки сотрудников внедрить новые подходы встречаются с мощным сопротивлением и редко бывают успешными). С падением общей полезности новых методологий падает и интерес к ним со стороны опытных управленцев/программистов.
Встает вопрос, а надо ли вообще заниматься трудным преодолением препятствий, когда выигрыш невелик. Ответ прост - лучше совершенствовать то, что ты уже выучил. Хороший структурщик работает намного быстрее и лучше его же перешедшего на ООП. Лишь спустя несколько лет наполненных матами и тяжелым трудом он освоит ООП на уровне себя самого прежнего. Эффективность вырастет ненамного, если вырастет. Ломать свои мозги для перехода на функционалку можно ради интереса, но не стоит ждать дождя из сокровищ. Исключения стоит делать только там, где методология дает явное преимущество.
Программистов надо использовать по их умениям, а не по текущим модным тенденциям. Выгоднее поощрять его совершенствовать текущие навыки чем ломать об колено накопленную многолетнию квалификацию. Постоянное давление СМИ, модных писателей, маньяков с горящими глазами мешает программисту работать как ему интересно и полезно делу.
Прогресс не остановить, но это не прогресс. Это типичная толпа, которая ломится на очередную моду заставляя более умных вовлекаться в бессмысленную гонку. На одно полезное новшество приходится сто пятьдесят инноваций сомнительно полезных в отдельных случаях. Безумная страсть к изменениям всячески поддерживается воротилами ИТ, менеджерами продаж и так далее. Коренной слом предыдущих технологий дает массу возможностей для впаривания новых продуктов, написания книжек и прочей платной деятельности. Прогресс сам по себе не важен. Важно под него устроить очередную перестройку с выниманием денег из карманов лохов.