Пишет тебе старый твой поклонник, скромный труженик клавиатуры, канаццкий программист Борис.
Вот уже много лет я являюсь тайным поклонником функционального программирования (FP). Чего-то там писал, чего-то там изучал, проникался. Наконец, решился написать в (максимально) функциональном стиле некую систему Х нетривиальной сложности.
Подновил свои знания в области Clojure, прикинул что и как можно сделать, из каких компонент система Х будет состоять. Мысленно сказал себе: "ну, давай, Доббс, действуй!".... и впал в кому.
Причиной комы, как выяснилось при вскрытии, был экстремально скоротекущий процесс Analysis Paralysis, симтоматика которого хорошо изучена и диагностика может быть сделана на глаз любым медиком средней руки — достаточно взглянуть на бессмысленно выпученные глаза и медленно шевелящуюся нижнюю челюсть больного.
Суть паралича в данном конкретном случае была в следующем:
1) Пациент хорошо владеет OOD (Object Oriented Design) и прекрасно представляет себе как спроектировать упомянутую систему Х используя ОО подход. Может разрисовать диаграммы сколь угодно глубокой детализации начиная от диаграмм классов и заканчивая sequence диаграммами.
2) Пациент имеет смутное представление о функциональном дизайне (SA/SD), а также помнит что данный способ разбиения систем на запчасти был признан убогим еще до его (пациента) рождения.
3) Пациент в состоянии пойти на компромисс с совестью и спроектировать систему Х крупноблочно в OOD стиле, а затем (закрыв глаза и очертя голову) реализовать каждую компоненту в функциональном стиле. Однако, такой подход кажется пациенту крайне неестественным. К тому же некоторые компоненты (в частности, компонента, реализующя persistence layer) настолько stateful что пациенту просто страшно представить как они будут выглядеть при чисто функциональном подходе. Уж лучше сразу махнуть рукой и сделать ОО компоненту чем так корячить FP.
Всвязи с этим пациенту требуется срочная госпитализация и помощь опытного хирурга по следующим главным направлениям:
4) У пациента складываетя прочное мнение что FP хорошо на микроуровне, там где модель поведения программы тривиальна либо заранее известна.
5) У пациента возникает ощущение что на глобальном архитектурном уровне FP не может решить его, пациента, проблем, а лишь добавит ему, пациенту, головной боли из-за попыток симулировать OOP на FP языке (да, дайте пациенту замыкания и он в три счета сделает вам из них ООП, но смысл?)
6) Пациент все больше разуверивается в FP как в парадигме, позволяющей ему, пациенту противостоять неизбежным изменениям в архитектуре, модели поведения, модели данных.
