Не в силах объяснить монаду
Нет, это не очередная попытка объяснить монады. Я не знаю, как это сделать и не могу представить, как бы я, например, из настоящего мог бы объяснить это себе из прошлого.
Это же касается и остальных концептов FP. Я понимаю их ценность, как ими пользоваться. Но я не знаю, как это донести до людей, которые изначально настроенны негативно к функциональному подходу. Не думаю, что это вообще возможно. Практика легко решает это дело, но до неё у людей редко доходят руки.
Я даже не знаю, как ответить на более простые вопросы. Несмотря на то, что пишу на Scala больше 3 лет, я не могу на пальцах объяснить преимущества языка для человека извне. Например, пару месяцев назад мне довелось провести не лучшую дискуссию.
Всё началось с вопроса: «А для кого вообще ваш язык написан?».
В моей голове вертелись все эти иммутабельности, функции высшего порядка, великая система типов, сайд-эффекты и прочие монады, но я понимал, что это всё не то. Последовавшее уточнение окончательно отправило меня в нокаут: «Вот, например, Java — это язык для белых воротничков». Тот диалог закончился какой-то несвязной ахинеей про невозможность объяснить разницу без практики.
Мы не умеем продавать FP
Это не просто пересказ личного опыта. Все мы, пользователи функциональных языков, находимся примерно в идентичной ситуации. Мы прекрасно понимаем огромную разницу в сравнении с Blub языками, но остальной мир не хочет нас слышать. Конечно, можно злиться на ограниченность консерваторов, которые хавают «Г», преспокойно несут чушь, пересказывают друг другу мифы и сказки, твёрдо и уверенно вступают в дискуссии о вещах, на которые даже пары часов не потратили. Можно также винить огромные корпорации с их отрядами маркетологов.
Но мне кажется, в первую очередь, проблема в том, что мы сами не умеем продавать FP. Да, это нелегкая задача. Хотя, когда я вспоминаю, как люди принимают решения, как и какие вещи входят в тренды, то начинаю думать, что это возможно.
В разработке всегда что-то не так.
- Процессы медленные! И вот уже через несколько лет каждое утро, во всех офисах страны люди, стоя у доски, перетаскивают стикеры из одной колонки в другую.
- Деплой медленный! И вот вооруженные ценностями devops, мы делаем по 10 релизов в день, в то время как новое поколение админов заливают это тоннами ruby, python и yaml.
- Приложения сложные! И вот команды в 2–3 разработчика сооружают новую микросервисную архитектуру, детально продумывая ответственности каждого сервиса и делая по 10 пул-реквестов на одну маленькую правку.
Не то чтобы я считал все эти повальные увлечения в индустрии плохими. Просто у них тоже есть немало недостатков. И не все умели или умеют их правильно готовить. Отсутствовал или отсутствует удобный тулинг. Тем не менее, эти подходы стали «де-факто» стандартными для индустрии. И хотя обсуждения про docker в продакшене для некоторых кажется еще не закрытым вопросом, всё уже произошло.
Я уверен, то же самое может произойти и с функциональными языками. Да, это не совсем корректно — сравнивать языки программирования с методологиями и подходами. Но нам есть что позаимствовать в их позиционировании для себя. У всех них есть строго определённая проблема, которую они решают. И это скорость: разработки, коммуникаций, планирования, деплоя, внесения изменений…
Почему мы забываем сказать о самом главном?
В тоже время, с точки зрения позиционирования функциональных языков программирования, сложно сказать что у них есть четкая и понятная цель. Языкосрачи »FP vs OOP» обычно быстро скатываются в мерянье фичами и концептами, ценность которых мало понятна OOP-лагерю. Статьи и доклады формата »Вы посмотрите, как эти монады великолепно композируются» чаще закрепляют в людях мнение, что это им не нужно, чем вдохновляют попробовать. Все эти взаимодействия, крайне редко отвечают на вопрос »А зачем это все? ». Красиво и лаконично? Ну в лучшем случае будет упомянуто о меньшем количестве ошибок.
Самое главное в использовании функциональных языков есть та же самая скорость разработки! И эта скорость достигается вот этими всеми скучными и пугающими терминами, концепциями и свойствами, выходящими из них. Более легкая композиция за счет функций высокого порядка — плюс к скорости разработки. Иммутабельность, помимо надежности и меньшего количества ошибок, равнозначна тому, что даёт больше времени на полезные вещи, вместо траты его на отладку, хотфиксы и поддержку. Ну и так далее, думаю, логика понятна.
Да, это звучит слишком просто и даже очевидно.
Да, я тут вообще не сказал ничего нового. Но важность формулировки и акцентов важна. К сожалению, так уж устроено наше мышление. Для того, чтобы рушить барьеры, одних объяснений недостаточно. Нужна практика! Необходимо, чтобы человек или компания захотели потратить на это время. Отсылки к «академичности» или к относительной красоте мало кого вдохновят провести несколько дней, чувствуя себя идиотом.
Стоит перестать строить из себя умников, сходу раскидываясь терминами направо и налево, доказывая превосходство своего любимого ЯП над Blub. Вместо того, чтобы доказывать полезность фичи X, гораздо проще ее использовать как объяснение какого-то более понятного свойства. Если это получилось у других техник, возможно, нам тоже пора уже взять на себя ответственность и твёрдо заходить с очевидных и простых вещей.
Так что в следующий раз при сложностях ответа на вопрос »А зачем? » не стесняйтесь заходить с козырей, таких как: более высокая скорость разработки, более дешевая поддержка, меньшее количество разработчиков.
Ах, и еще. Ивенты для сообществ тоже играют не малую роль в позиционировании!
Поэтому, мы ждем всех неравнодушных к FP на единственной функциональной конференции в России — FPURE — Казань — 24–25 мая.
В программе: Haskell, Scala, Elixir, Clojure, теория и практика, и конечно же много единомышленников с кем найдется о чем поговорить!
