В первой части серии я начал обсуждение некоторых особенностей функционального программирования, показывая проявления этих идей в Java и других, более функциональных языках. В этой статье я продолжу свой обзор, обращая внимание на функции — объекты первого класса, оптимизации и замыкания. Но основная тема этой статьи — контроль: когда вы его хотите, когда он вам необходим и когда надо просто забить.

Давайте на мгновение представим, что Вы — дровосек. И благодаря своему лучшему топору в округе, вы являетесь самым продуктивным дровосеком в лагере. Но однажды появляется некто, начинающий расхваливать достоинства новой парадигмы в рубке леса — бензопилы. В силу убедительности продавца, Вы покупаете бензопилу, но не знаете как она работает. Прилагая неимоверные усилия, пробуете вырвать или раскачать дерево, применяя на практике свою новую парадигму. И быстренько делая вывод, что эта самая новомодная бензопила — ерунда, возвращаетесь к привычному делу — рубить лес топором. А затем кто-то приходит и показывает как заводить бензопилу.

Эта история может показаться Вам знакомой, поставив функциональное программирование на место бензопилы. Проблема в совершенно новой парадигме программирования — не изучение нового языка. Более того, синтакс языка — это всего лишь детали. Вся тонкость же — научиться мыслить иначе. Это то, почему я оказался тут — заводящий бензопилы и “функциональный” программист.

Итак, добро пожаловать в Functional thinking. Эта серия исследует предмет функционального программирования, но не несет исключительной направленности описать функциональные языки. Как я покажу дальше, написание кода в функциональном стиле касается дизайна, компромиссов, разных повторно используемых кусков кода и служит основой для иных догадок. Насколько это окажется возможным, я попытаюсь показать концепции функционального программирования в Java (или близких к Java языках) и перейду к другим языкам, чтобы осветить возможности, отсутствующие на данный момент в Java. Я не полезу сразу в дебри, рассказывая о довольно необычных вещах, таких как монады (monads). Напротив, я постепенно проведу Вас через новый путь мышления.

Эта и пара следующих частей выступят в роли быстрой экскурсии по предметам, связанным с функциональным программированием, включая базовые концепции. Некоторые из этих концепций в дальнейшем будут рассмотрены более детально в то время, как я буду постепенно расширять контекст применения на протяжении всей серии. В качестве отправной точки нашей экскурсии я покажу Вам две разные реализации решения задачи. Одна написана в императивном стиле и другая — с некоторыми функциональными особенностями.

Для начала, позвольте уточнить, что я являюсь большим любителем и сторонником Scala вот уже 5 лет. Мною были написаны книги и статьи о Scala. Также я работал со множеством компаний, начавших использование Scala и Lift и проводил code review огромного количества Scala — проектов. Раньше я думал, что Scala — это просто. Она была и продолжает быть лекарством от многих проблем Java. С точки зрения “сложные или вообще невыполнимые вещи в Java довольно просты в Scala”, Scala — довольно простой язык. Работа с коллекциями очень проста. Изоляция бизнес-логики делает программы гораздо более поддерживаемыми и невероятно простыми, чем если бы они писались на Java.
Так почему же Scala сложна? Вот лучшее, что я смог придумать:

Почему Groovy

Будучи Java разработчиком, некоторое время назад я начал посматривать в сторону других языков программирования, и, думаю об этом размышлял далеко не только я. Некоторые мои знакомые, в свое время имеющие отнюдь не малый опыт в разработке под Java — платформу, решительно начали двигаться по рельсам (Rails), соответственно используя Ruby, кто-то еще подумывает приручить Питона с приложением к нему в виде Django. Появляется достаточно книг о том, как Java — программисту мигрировать в мир динамических языков. Может ли что-то нас остановить?