Перед вами любительский перевод эссе Эрика Норманда — консультанта и спикера, продвигающего функциональное программирование.
Я был довольно волен с терминами, не стеснялся использовать англицизмы вроде "фича". Меня смущает дословный перевод программистских терминов. Приятного чтения
Резюме: мы отвечаем на вопрос напрямую, но потом разбираем предубеждения, скрытые за ним.
Довольно часто опытные разработчики спрашивают меня: "Что может дать мне функциональное программирование такого, чего у меня нет? Могу ли я просто начать использовать ФП на своем языке?". Это отличный вопрос, я надеюсь, что смогу дать на него достойный ответ.
Мне совершенно понятно появление данного вопроса. У JavaScript есть map
, filter
и reduce
. У Java 8 есть стримы (решил использовать англицизм вместо слова "поток" — прим. переводчика). Похоже, каждый язык получает все больше функциональных фич, в т.ч. неизменяемые структуры данных, функции первого порядка, композицию функций, деструктурирование и хорошую типизацию.
И я согласен: вы можете применять ФП в любом языке.
Функциональное программирование — это всего-лишь парадигма. Точно так же, как вы можете писать в процедурном, объекто-ориентированном или логическом стиле на любом языке, вы можете писать в функциональном стиле на любом языке.
Минуточку. Это и есть ответ на поставленный вопрос. Но все ли так просто?
Задайтесь вопросом: можно ли использовать ООП в языке C? Согласно тому, что я сказал выше, ответ положительный. Более того, я уже делал небольшие объектные системы на C ранее. Но зачем тогда мне объектно-ориентированный язык, если я могу использовать объекты в C? По ощущениям, моя объектная система предоставила мне все возможности, необходимые для ООП. Но вот другой вопрос: мог ли бы я использовать ООП в C, не зная ООП? Сомневаюсь.
Эти парадигмы называются парадигмами, т.к. это целостные подходы к тому, как решать задачи. ООП делит задачу на объекты, которые взаимодействуют друг с другом с помощью сообщений. ФП представляет задачу, как данные, которые отображают состояние моделируемого процесса. Процедурный подход описывает решение как набор четких шагов. Каждая парадигма предлагает разный способ решения задачи. Если вы считаете, что можете использовать ФП в Java, не являясь специалистом в ФП, то вы утверждаете, что функциональное программирование — не парадигма, а просто набор фич (неизменяемые данные, чистые функции, их композиция и т.п.).
Я многократно сталкивался с этим. Люди утверждают, что пишут в функциональном стиле на JavaScript. На самом же деле они просто используют map
и reduce
вкупе с некоторым количеством чистых функций. И это дает неплохие плоды, но в целом их код процедурный. Они изучили не парадигму, а всего-лишь ее фичи.
Плюс языка, который жестко навязывает парадигму, заключается в том, что он учит вас использовать данный подход к решению задач. И чем сильнее он ее навязывает, тем чаще вам придется пытаться решить задачу в рамках данной парадигмы. Чем более функционален ваш язык, тем больше вы натренируетесь использовать функциональный подход при решении задач. То же самое относится к ООП и процедурному стилю. Если коротко, вы тренируетесь засчет того, что не можете использовать подходы к которым уже привыкли.
Позвольте мне выразить еще более спорное утвержение: вне языков, которые являются функциональными (Clojure, Haskell, Elm, Scala, Erlang и т.д.), не так уж много ФП используется. Кроме случаев, когда разработчики уже знакомы с функциональным стилем, благодаря богатому опыту, они используют лишь крохи того, что предлагает парадигма. И они упускают самое главное: возможность взглянуть на задачу под другим углом.
Я не говорю, что невозможно в действительности выучить ФП с помощью JavaScript, но для этого потребуется самодисциплина и помощь. Язык не будет вас наставлять на этом пути. Вам придется делать это самому, либо найти того, кто вам поможет.
Заключение
Все парадигмы превосходны, т.к. "одна точка зрения равноценна 80 очкам IQ". Вы можете использовать любую парадигму на любом языке. Но очень сложно изучить парадигму, не погружаясь в нее. И довольно сложно погрузиться, не используя язык, навязывающий ее. Пока вы этого не сделаете, вы будете использовать фичи парадигмы, но не решать задачи новым способом. В общем, функциональное программирование — это не набор фич. Если вы хотите выучить его — погрузитесь в него.
nikbond
Такое ощущение, что основная часть статьи потерялась. Только началось вступление, а за ним сразу выводы.
questor
Оригинал столь же краток, как и перевод. В топку такие статьи-лозунги. Если нет содержательной части, выводы не подкреплены фактурой — то это просто рекламный материал в 140 символов, не более: «пишите в ФП стиле», «чистите зубы», «делайте гимнастику».
Я не то, чтобы против использования ФП, просто оскоблён в своих лучших чувствах: зашёл в статью, а после ката и статьи-то никакой нет. При всей правильности тезиса статьи, саму статью ещё только предстоит написать и перевести.
Nondv Автор
Вы ведь понимаете, что эта статья не о функциональными программировании? Да, я соглашусь, что это в некоторой степени реклама (автор этим на жизнь зарабатывает). Но Вы не правы, думая, что она о ФП.
Эта статья (эссе?) — мнение автора на довольно распространенную тему с позиции опыта и здравого смысла — двух вещей, которых нам, разработчикам, не хватает больше всего.
В ней поднимается распргстраненное явление, что вместо того, чтобы изучать подход и идеологию в целом, люди изучают отдельные приемы.
И я считаю, что такие короткие эссе (да, наверное, я погорячился со словом "статья") абсолютно необходимы нам, т.к. они воспринимаются гораздо проще, чем подробные гайдлайны и пр. Они позволяют нам понять, зачем нам в принципе это нужно (или не нужно), и сподвигнуть на чтение этих самых гайдлайнов. И мне очень понравилось прочитанное, поэтому я и решил поделиться этим с сообществом, постарвшись сделать качественный перевод.
ZurgInq
Тут есть хороший посыл, что использование фич из ФП не равно программированию в функциональном стиле, и что бы научится программировать в функциональном стиле, необходимо использовать функциональный ЯП.
Nondv Автор
Истинно так. То же самое относится и к другим парадигмам.
Я вот лично не уверен, что смогу хорошо писать в процедурном стиле, хотя они очень близки с ООП (оба императивные и т.п.). Одна из причин, почему хочу попробовать Golang. С другой стороны есть подозрение, что я просто буду перетаскивать свои ООП-привычки и язык мне не поможет =)
Еще довольно занятной мне кажется концепция прототипно-ориентированности в JS. Однако, насколько я могу судить, ее никто не использует, предпочитая класс-ориентированность.