Почему вы должны думать о функциональном программировании

Привет, Хабр! Представляю вашему вниманию перевод своей статьи «Why you should think about functional programming», посвященной функциональному программированию.

image

Почему вы должны думать о функциональном программировании? Давайте ответим на следующие вопросы:

  • всегда ли ваши проекты выполняются в определенные сроки?
  • Были ли у пользователей какие-либо жалобы?
  • Поддержка проекта никогда не занимала много времени?
  • Новый функционал всегда удачно вписывается в существующую архитектуру?

Если ответы на все вышеупомянутые вопросы положительные, вам не нужно ничего менять, ваша команда — редкий пример гармоничного персонала, методологии и инструментов. В противном случае вы должны быть открыты для новых подходов к решению ваших проблем, включая критический взгляд на используемые технические средства и языки программирования.

Первый взгляд


Как вы знаете, программисты — чрезвычайно креативные люди, но в то же время они склонны следовать некоторым тенденциям при выборе языка программирования. Среди огромного количества языков функциональные языки все больше приобретают фанатов и ими все больше уверенно пользуются компании по всему миру. Использование функциональных языков может значительно повысить производительность и качество работы программистов. Естественно, это зависит от сочетания задач, языка и навыков программирования. В этом случае программист просто описывает, что он хочет, вместо перечисления последовательности действий, необходимых для получения результата. Таким образом, разработчик сосредотачивается на высоко-уровневом «что требуется» вместо того, чтобы застрять на низкоуровневом «как это сделать».

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

Итак, если любая задача может быть решена путем объединения вызовов нескольких функций, то:

  1. Как реализовать условия if-else?
  2. Как решить трюки с Null Exception?
  3. Как убедиться, что функция действительно «многоразовая» и может использоваться где угодно?
  4. Как сделать так, чтобы данные, передаваемые нашим функциям, были изменены и могли использоваться в других местах?
  5. Если функция принимает несколько значений, но при объединении в цепочку вы можете передать только одну функцию, то как нам сделать эту функцию частью цепочки?

Чтобы решить все эти проблемы, функциональные языки предоставляют инструменты и решения из математики, такие как монады, функторы и так далее.

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

Так почему же эксперты так долго упускают из виду функциональное программирование? И почему это становится таким распространенным сегодня?

Где функциональное программирование используется в реальном мире?


Поскольку функциональное программирование — это прежде всего подход к написанию кода, вы можете использовать его принципы на любом языке. Однако есть языки, специально отточенные функциональным подходом. Более современные функциональные языки, такие как Elm и Elixir, согласно GitHub и Stack Overflow, постепенно и уверенно набирают популярность. Растущая популярность JavaScript также привела к повышению интереса к концепциям функционального программирования для использования на этом языке. Кроме того, опытные разработчики в области функционального программирования впоследствии начали работать над средами Single Web Application — SPA, и в результате у нас есть Redux, React, MobX и другие библиотеки, используемые миллионами людей.

image

Примеры из реальной жизни:

  • Apache Spark
  • Scalding (от Twitter)
  • Apache Kafka
  • Finagle (от Twitter)
  • Akka
  • Autocad
  • emacs (LISP)

Так что же такое функциональное программирование, откуда взялся такой бум и почему его стоит рассмотреть? Давайте разберемся.

О функциональном программировании


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

  • функциональное программирование позволяет писать более лаконичный и предсказуемый код
  • это легче проверить (хотя учиться с нуля нелегко)

Ключевые особенности разработки программного обеспечения с использованием функционального программирования


  • Чистая функция очень проста. Он всегда должен возвращать один и тот же результат. При одинаковых значениях Х и Y мы всегда получим один и тот же результат функции. Предсказуемость играет важную роль во время работы программы в функциональном программировании.
  • Избегать общего состояния, изменчивых данных и побочных эффектов;
    Неизменяемый объект — это объект, состояние которого нельзя изменить после его создания. Неизменяемые объекты более потоко-ориентированы, чем изменяемые объекты. Если функция не работает предсказуемо — это приведет к нежелательным побочным эффектам. В императивных языках функция в процессе реализации может считывать и изменять значения глобальных переменных и выполнять ввод / вывод. Поэтому, если мы вызываем одну и ту же функцию дважды с одним и тем же аргументом, может случиться так, что мы получим два разных результата. Такая функция называется побочным эффектом.

    Функциональное программирование помогает нам писать потоко-ориентированный код.
  • Распространенность декларативного, а не императивного подхода.

Композиция функций


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

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

image

Преимущества функционального программирования


Функциональное программирование помогает сделать код более понятным, предсказуемым и легким для чтения. Использование принципов функционального программирования помогает избавиться от ненужных абстракций с непредсказуемым поведением, поэтому сделать программу более предсказуемой и уменьшить количество возможных ошибок.

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

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

Недостатки функционального программирования


  • Одна из проблем функционального программирования заключается в том, что оно отличается от того, что вы уже знаете. Вы должны заново выучить многое из того, что вы уже знаете в императивной обстановке! Многие опытные разработчики, которым уже знакомо то, что они уже знают, не собираются решать проблемы по-другому. Требуется время и усилия, чтобы думать по-другому.
  • Легко написать чистые функции, но объединить их в законченное приложение — вот где все становится сложнее.
  • Большая проблема с предсказуемой производительностью. Использование только неизменяемых значений и рекурсии может потенциально привести к проблемам с производительностью, включая использование ОЗУ и скорость, поэтому большинство функциональных языков не являются особенно хорошим выбором для мягких или жестких систем реального времени или встроенных вычислений.
  • Функциональное программирование имеет тенденцию писать код в слишком абстрактной форме, когда сам программист больше не понимает, что он написал через некоторое время.
  • Чистые функции и ввод / вывод на самом деле не смешиваются.

Заключение


Если вам и вашей команде разработчиков кажется, что ваш стиль кодирования не дает вам необходимого уровня управления сложностью бизнес-области, засоряя ваш код ненужным синтаксическим мусором, что приводит к потере времени, попробуйте функциональное программирование. Таким образом, в областях, связанных с большим количеством вычислений или преобразований данных, параллельным / асинхронным программированием, вы можете получить значительные преимущества, погрузившись в функциональное программирование.

Написание кода на функциональном языке дает вам возможность взглянуть на проблему с другой стороны, где разработка вашего решения может быть более эффективной. И это просто увеличит количество способов выразить ваши идеи.

Разрабатывая свое решение с использованием парадигмы функционального программирования, вы будете все быстрее и быстрее ускорять весь процесс разработки, становясь все более опытным. Похоже, вы ведете свой автомобиль на повышенной передаче, в сравнении с тем, как движутся программисты-императивщики.

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

image

Если вы все сделаете правильно, результат будет более понятный, лаконичный и вы будете иметь читабельный код. Разве это не то, что мы все хотим?

Роман Талуев,
разработчик программного обеспечения в Quasarbyte
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 59

    +14
    всегда ли ваши проекты выполняются в определенные сроки?
    Были ли у пользователей какие-либо жалобы?
    Поддержка проекта никогда не занимала много времени?
    Новый функционал всегда удачно вписывается в существующую архитектуру?


    А другие люди для решения тех же проблем предлагают Scrum.
    Я к тому, что проблемы такие есть, но они комплексные и далеко не факт, что к ним приводит использование ООП, а решить их поможет мышление в функциональном стиле.

    Может быть, имеет место просто ошибка выжившего, потому что можно написать плохой код, пытаясь сделать программу в ООП или структурном стиле, но в функциональном стиле просто ничего не заработает (например, пока ты не поймёшь что такое map, filter и reduce и как они работают, ты даже написать компилирующуюся программу с ними не сможешь, в этом плане ФП проще, а ООП — easy to «learn», hard to master). Или потому что ООП — до сих пор мейнстрим, то до ФП доходят лишь немногие, т.е. люди уже опытные, люди занимающиеся профессиональным развитием, т.е. по определению лучшие программисты.

    Я почему-то не сомневаюсь, что если Рича Хики попросить написать программу на Java (очень попросить), а Скотта Влашина — на C#, а Джеральда Сассмана — на C, то они напишут просто отличный код. Точно также мне кажется, что человек, который ушёл с Java на Clojure, или с C# на F#, или с C++ на Haskell, лучше знает Java/C#/C++, чем человек, который ни о чём больше не слышал/ничего больше даже не пробовал/ничего больше даже не искал.
      +5
      Утверждение
      Функциональное программирование помогает сделать код более понятным, предсказуемым и легким для чтения

      противоречит вот этому
      Функциональное программирование имеет тенденцию писать код в слишком абстрактной форме, когда сам программист больше не понимает, что он написал через некоторое время.
        0

        В общем-то стоит это расценивать так — ФП помогает сделать код более понятным, предсказуемым и лёгким для чтения, так как предоставляет мощные средства для абстрагирования. С другой стороны из-за этого появляются две проблемы, одна минорная, другая мажорная:


        • минорная — больше способов написать излишне абстрактный код
        • мажорная — люди, которые не изучили какие-то фичи/либы, в связи с чем считают код с их использованием нечитаемым, а так же транслируют это мнение в массы

        Прекрасный пример второго явления — линзы. Есть кто не понимают их и поэтому считают код с ними нечитаемым, а есть те, кто не поленился таки прочитать по ним туториал.

        –1

        Что же вы не приложили пару строчек ФП кода? Сразу стало бы ясно на сколько функциональный подход превлекателен людям. Побазарить на тему программирования все могут, а как только появляется код то топик сразу скатывается в минус. ФП плохо тем, что на нем сложно делать простые вещи, а сложные ваще не возможно. ФП это только для обработки списков, и то с++ в этом рулит больше. Как насчёт стандартной обработки списков с разнародными элементами, в с++ это есть. А ФП даже в этом не преуспевает.

          0

          Отвечу пастой:


          Я много раз пытался объяснить людям положительные стороны функций, но все бестолку. Они ждут что им на пальцах, за пару часов расскажут о целой парадигме. Хотя никто не ожидает что ООП можно объяснить в тот же срок. Люди годами его изучают, придумывают принципы, мнемоники и паттерны. Причем основная масса так никогда его и не осиливает. Но вот функции обязательно надо раскрыть в одной статье. Почти каждый кто стал на них писать не может нарадоваться и всячески толкает и в мир, но для вас это не показатель. Притом что им уже 60 лет. А вот очередное хайповое говно от очередного Гугла учите только так.
            –4
            Ассемблер умиляет 60 летних.
            Вся эта байда с ФП не стоит ни чего. Все из-за стогнации сегмента программирования в последнее время. Библиотеки не поддерживаются, языки меняются. Даже в MIT перестали читать курс о LISP. В свое время читал книгу по LISP. Но скоро понял, что работадателям не интересно ФП. Можно даже сказать, что ФП очень спорная ветвь развития языков программирования. Может комуто и нравится думать как программист функциональщик. Но это всего на пару лет. Потом все выветривается из головы, т.к. мало поддерживается. Книги по ФП очень обстрактные. Не хватает примеров в интернете. А жести и без ФП хватает в ООП.
            На счет хайпа могу сказать, что отрасль программирования сама по себе хайповая штука. С ФП хайповый подход не работает. Т.к. за ФП не платят денег, то ФП ни стоит ни чего. Можно только в институте рассказывать как хорошо программировать на ФП и то не весь семестр. Да и функциональщики — народ ленивый. Вместо того, чтобы писать примеры в интернете работающих кейсов они пишут водянистые статьи на хабре.

              +1
              Вы по-русски-то плохо пишете («обстрактные», «ни чего», «стогнации», «комуто», — всё это не единичные описки, это стиль программирования письма, показатель отношения к потенциальному читателю), но так «авторитетно» пишете, будто всё обо всём знаете. Спорная ветвь! Ничего не стоит! Ха-ха. Именно поэтому в C# продолжают добавлять сопоставление с паттерном, именно поэтому так много проектов на Scala, из-за спорности, конечно.

              Существует огромное количество книг по функциональному программированию. Выберите по ближайшему к Вашему стеку ФП-языку и начинайте читать системно. Или не приставайте к авторам ненавистных Вам «водянистых» статей.
              +1
              А можно ссылки на проекты, где основная кодовая база написана на функциональном языке? Ну чтобы понимать, что ФП реально применимо, а не только поиграться.
                0
                Например, хотя где-то была статья с разбором утверждающая что больша часть этих примеров не очень корректна.
                  0

                  RSS агрегатор bazqux.com написан на хаскеле.

                    0
                    на ocaml-е вроде ведь?
                      0

                      В faq https://bazqux.com/faq автор пишет:


                      Is BazQux Reader really written in Haskell and Ur/Web?
                      Yes. I love to use the best tools available.
                    0
                    jet.com на F# написан.
                      0
                      Scala считаем функциональным? :) Тогда например Spark, чем вам не пример?
                  –2
                  Хмм…
                  Никакого ООП… Только процедуры и функции, вызываемые в определенной последовательности…
                  Неужто это
                  Тот самый стиль, которым [почти]все мы писали в школе на паскале/дельфях, это самый стиль — сейчас в тренде? )))
                    +1

                    В ФП и правда принято разделять данные и способы их обработки. Но всё же программы на ФП представляются не процедурами и функциями вызываемыми в определённой последовательности, тут автор ошибся. Программы на ФП являются выражением, редукция которого и является исполнением программы.

                      0
                      Нет, вы полностью не поняли о чём речь, ФП это не отказ от ООП, это другой подход, данные неизменяемы, циклов нет и т.п.
                        0
                        В Паскале функция — всего лишь процедура, которая может вернуть значение.
                        Да, можно на Паскале написать все на функциях, но…
                        Это не функкциональное программирование в широком смысле слова — это процедурное.
                        Основное, чего не хватает в Паскале (чтобы быть функциональным) — это функций как объекта первого класса и функций высшего порядка, но это будет уже не Паскаль.
                        –1
                        Сделал прототип идеи интуитивного способа программирования, похоже ли такое на функциональное программирование?:

                          +1
                          А есть какие-нибудь актуальные данные о производительности, потреблении ресурсов и возможностях оптимизации в ФП?
                          Как-то интуитивно всё это удовольствие выглядит сильно оторваным от реального железа и происходящих там процессов.
                          На сколько свободно функциональщих может контролировать итоговый код который будет выполняться? Рекурсии, лямбды, линзы это не бесплатно ж всё.
                          Обычно покупателя в итоге интересует скорость и стабильность работы готовой программы, а не абстрактная «красота кода»/
                            +1
                            тыц, хотя пример специфический, но в целом насколько я помню хаскелл один из самых производительных языков, но подводные камни есть — из-за ленивости иногда могут быть большие проблемы с памятью и нужно об этом помнить.
                              +1
                              Спасибо. Пример, конечно, спорный :) но пока копался в поисках опровержений пришло таки осознание того что ФП — это таки парадигма, а не конкретный компилятор/среда разработки. И, если не учитывать «набирающий популярность js», действительно может лучше работать на каких-то задачах. Что-то оно действительно позволяет оптимизировать и улучшать, что-то усложняет. Как минимум, для общего развития разобраться будет не лишним.
                                +1
                                Haskell, как изначально функциональный язык имеет специально оптимизированную виртуальную машину. Функциональным языкам, к примеру на JVM (Scala) или на .Net (F#), приходится использовать то, что есть в этих, изначально императивных VM. Поэтому в них некоторые сугубо функциональные вещи будут работать медленнее.
                                  0
                                  deleted, промахнулся веткой.
                                  0
                                  Тут было недавно два замечательных поста. Первый — про написание кода на хаскеле, второй — про оптимизацию. В принципе, они отвечают на ваш вопрос. Начать можно со второго из них.
                                  +2

                                  Почему НЕ стоит использовать функциональное программирование (в бизнес-приложениях)?


                                  • менталитет людей не поменять, зачастую описание (и понимание) задачи приводится императивно ввиде линейного бизнес-процесса или алгоритма
                                  • многие ФП-языки не типизированные со всеми вытекающими проблемами
                                  • устаревший и непривычный синтаксис (и понятия) более близкий к математике, нежели к бизнесу
                                  • система типов базируется на сложных для понимания абстрактных понятиях
                                  • невозможность привычного дебага
                                  • отсутствие стейта и сложность мониторинга
                                  • параллельный мир: сложно интегрировать с уже существующими не ФП-технологиями (коих чуть менее, чем все), особенно там, где появляется state или IO и функции перестают быть чистыми.

                                  Поэтому реально ФП имеет смысл использовать в отдельных законченных модулях типа разбора выражений и rules engine, но писать все приложение на ФП не имеет большого смысла.

                                    +2

                                    Ниже я буду говорить в первую очередь о Haskell


                                    менталитет людей не поменять, зачастую описание (и понимание) задачи приводится императивно ввиде линейного бизнес-процесса или алгоритма

                                    Так оно работает разве что с программистами. Обычно люди разговаривают и объясняют задачи на языке вообще не предназначенном для программирования, часто смешивая императивное "как" и декларативное "что". Более того, обычно объяснения настолько высокоуровневые, что полностью абстрагированны не то что от императивного потока исполнения обычного языка программирования, а даже от жизненного цикла программы.


                                    многие ФП-языки не типизированные со всеми вытекающими проблемами

                                    Наиболее развитые системы типов встречаются именно в ФП, кроме того, типизация в императивных языках развивается только на основе прогресса в области ФП.


                                    устаревший и непривычный синтаксис (и понятия) более близкий к математике, нежели к бизнесу

                                    Был уже как-то язык, который был "близок к бизнесу", COBOL назывался, и что в итоге? При этом наиболее популярные нынче C-подобные языки близки к бизнесу примерно никак. "Математичность" же синтаксиса — это реализация вполне разумного стремления сделать код читаемее человеческой речи, которая плохо структурированна, не имеет ни операционной, ни денотационной семантики и вообще слабо подходит для описания вычислений. Попробуйте заменить все формулы в учебниках по математике, физике, химии и инженерному делу на словесные описания — да люди потом замучаются это всё читать.


                                    система типов базируется на сложных для понимания абстрактных понятиях

                                    Любая система типов базируется на одном и том же. Разве что если в системе типов фич больше, то и теория под ней, вероятнее всего, обширней. Но фичи, знаете ли, вводятся не затем, чтобы сделать что-то сложнее и элитарнее.


                                    невозможность привычного дебага

                                    Во первых, привычный дебаг возможен. Во вторых, есть и другие, не менее удобные инструменты отладки, например REPL. В третьих, система типов не даст допустить таких глупых ошибок, какие часть можно встретить в программах на императивных языках.


                                    отсутствие стейта и сложность мониторинга

                                    Стейт есть, и, если надо, даже мутабельный, к тому же он выражается на уровне типов. Что значит сложность мониторинга?


                                    параллельный мир: сложно интегрировать с уже существующими не ФП-технологиями (коих чуть менее, чем все), особенно там, где появляется state или IO и функции перестают быть чистыми.

                                    Да, действительно, проблема есть. Так же как и проблема того, что существующих не-ФП технологий не так много. Именно поэтому тот же Haskell обычно используют там, где готовых решений не так уж и много, а большую часть кода придётся писать самостоятельно независимо от выбора языка.


                                    В общем-то все эти претензии вместе взятые выглядят как "это не императивное программирование, меня этому не учили, мой опыт императивного программиста на этот глобус не натягивается, мне это не нравится, да и тратить своё время на то, чтобы этому учится, я не хочу".

                                      0
                                      Обычно люди разговаривают и объясняют задачи на языке вообще не предназначенном для программирования, часто смешивая императивное "как" и декларативное "что".

                                      Как раз человеку очень хорошо понятна последовательности действий, которая интуитивно связана с концепцей времени. И на этом языке можно вести диалог с заказчиком: сходи туда, получи такие-то данные, вызови этот интерфейс, затем вычисли то, и сохрани там и т.д… Фраза "копать от забора и до обеда" понятна любому солдату, тогда на ФП это будет бред вроде: "для обеда смотри: забор? копай метр, иначе смотри предыдущий метр и копай метр".


                                      Был уже как-то язык, который был "близок к бизнесу", COBOL назывался, и что в итоге?

                                      До сих пор индустриальный стандарт в банковской системе, а специалисты по нему наиболее высокооплачиваемые. Но не суть.


                                      "Математичность" же синтаксиса — это реализация вполне разумного стремления сделать код читаемее человеческой речи, которая плохо структурированна, не имеет ни операционной, ни денотационной семантики и вообще слабо подходит для описания вычислений.

                                      То есть вас не смущают в Scala идентификаторы, составленные из символов !\$%&/|, которые к тому же могут оказаться вообще всем чем угодно. То есть любой человек, взглянув на код "a! b" без детального анализа контекста сразу же поймет, что это эквивалентно a.sendMessage(b), только гораздо лаконичнее и математичнее. Императивные языки используют минимальный набор простых и понятных управляющих статичных конструкций (в минимуме — условие и цикл), в то время в функциональном языке вся логика — это композиция вычислений, к тому же динамически связанная.


                                      Но фичи, знаете ли, вводятся не затем, чтобы сделать что-то сложнее и элитарнее.

                                      Этим и отличаются академические языки от промышленных. В академических (таких как Хаскель или Скала) фичи вводятся просто чтобы было, например на основе чьей-то научной работы. Затем некоторые из них мигрируют в той или иной форме в промышленные, и только когда доказана их полезность.


                                      В общем-то все эти претензии вместе взятые выглядят как "это не императивное программирование

                                      Точно также можно сказать в ответ, "я выучил ФП, и теперь все, кто его не умеет или не хочет — говно".
                                      Мои претензии — это не стоит рекламировать ФП как универсальную парадигму для всего (впрочем как и любую другугю). Количество задач там, где ее применение оправдано, достаточно ограниченно (посмотрите: сейчас это в основном потоковая обработка данных и распределенные вычисления). Для остальных задач проще и дешевле использовать традиционный подход.

                                        +2
                                        Как раз человеку очень хорошо понятна последовательности действий, которая интуитивно связана с концепцей времени. И на этом языке можно вести диалог с заказчиком: сходи туда, получи такие-то данные, вызови этот интерфейс, затем вычисли то, и сохрани там и т.д…

                                        Да, а ещё человек вместо скажет "возьми все записи повявившиеся после T времени", что уже вполне себе декларативно. Судя по вашему высказыванию — моё вы даже не пытались читать. Я говорю, что человек говорит не на языке программирования, это раз. Два это то, что на функциональных языках тоже можно писать императивные сценарии, но, в отличии от императивных языков, это можно делать на достаточно высоком уровне абстракции, чтобы приблизиться к человеческому описанию.


                                        До сих пор индустриальный стандарт в банковской системе, а специалисты по нему наиболее высокооплачиваемые. Но не суть.

                                        Интересное у вас отношение к дремучему легаси.


                                        То есть вас не смущают в Scala идентификаторы, составленные из символов !$%&/|, которые к тому же могут оказаться вообще всем чем угодно.

                                        В хаскеле они меня точно не смущают потому-что:


                                        • как правило это часто используемые стандартные операции
                                        • чем угодно они оказаться могут лишь настолько же, насколько чем угодно может оказаться функция, имя которой написано латинскими буквами

                                        То есть любой человек, взглянув на код "a! b" без детального анализа контекста сразу же поймет, что это эквивалентно a.sendMessage(b), только гораздо лаконичнее и математичнее.

                                        Не поймёт, но, во первых, не разу не видел, чтобы операторы для таких штук использовали, а во вторых, и a.sendMessage(b) много информации человеку не даст.


                                        Императивные языки используют минимальный набор простых и понятных управляющих статичных конструкций (в минимуме — условие и цикл)

                                        Из-за этого все программы на императивных языках очень низкоуровневы и далеки от предметной области решаемой проблемы.


                                        в то время в функциональном языке вся логика — это композиция вычислений, к тому же динамически связанная

                                        Что подразумевается под динамическим связыванием? Это вроде как в джавах всяких активно используют полиморфизм подтипов, тайпкастинг и null-reference, не? Да и что плохого в композиции вычислений? Считаете, что использование каждый раз новых велосипедов вместо переиспользования один раз написанного кода лучше?


                                        Этим и отличаются академические языки от промышленных. В академических (таких как Хаскель или Скала) фичи вводятся просто чтобы было, например на основе чьей-то научной работы. Затем некоторые из них мигрируют в той или иной форме в промышленные, и только когда доказана их полезность.

                                        А доказанной полезность фичи является видимо тогда, когда какой-нибудь старый сумасшедший (но очень уважаемый в IT) дед скажет, что она нужна, да?
                                        Мне вот лично совершенно непонятно как можно объективно доказать пользу/вред фичи без введения её в какой-то популярный язык и последующего подробного исследования её использования. Субъективно же обычно те, кто освоил фичи из ФП на должном уровне, уже не хочет от них отказываться.


                                        "я выучил ФП, и теперь все, кто его не умеет или не хочет — говно"

                                        Я говорил о том, что люди не хотят учится, но при этом любят высказать своё мнение о предмете, о котором знают примерно ничего. При чём тут моё отношение к таким людям и их мнению — совершенно непонятно? Я должен считаться с такм мнением, уважать его?


                                        Мои претензии — это не стоит рекламировать ФП как универсальную парадигму для всего (впрочем как и любую другугю). Количество задач там, где ее применение оправдано, достаточно ограниченно (посмотрите: сейчас это в основном потоковая обработка данных и распределенные вычисления).

                                        Вообще-то стоит, ибо почти все ограничения применения с ФП связанны лишь с его непопулярностью.


                                        Для остальных задач проще и дешевле использовать традиционный подход.

                                        При этом увеличение доли чистых функций и уменьшение доли мутабельного стейта практически всегда повышает качество и поддерживаемость кода.

                                          0

                                          Хорошо, я вас понял. Зайдем с другой стороны. Ответьте тогда на вопрос, почему на сегодняшний день при всех своих очевидных преимуществах ФП-языки так не популярны? Более того, за всю историю они никогда не были особо популярными? И тенденция к их популяризации в будущем тоже не радует. О них внезапно всмопнили десять лет назад, когда понадобилось масштабировать параллельные вычисления. Какой вы можете назвать общеизвестный проект, который написан на вашем любимом Хаскеле? У какого ФП-языка экосистема хотя бы приблизилась к объему C/C++/Java/JS? И какие будут соображения о причинах этого? Можете даже выбрать:


                                          • ФП сложны для понимания. Большинство людей обходится более простыми и понятными методами.
                                          • ФП не обучают в ВУЗах. На рынке мало специалистов по ФП, а соответственно возрастают риски и стоимость проекта.
                                          • ФП эффективны в решении определенного круга задач, но не подходят в качестве универсального инструмента.
                                          • ФП не подходят для больших проектов и не совместимы с используемыми там методологиями.
                                          • На ФП плохо моделировать предметную область, например сущности и отношения.
                                            +1
                                            Ответьте тогда на вопрос, почему на сегодняшний день при всех своих очевидных преимуществах ФП-языки так не популярны?

                                            Исторически так сложилось. Процитирую одного умного человека: "Одно из характерных качеств хаcкеля как языка и сообщества в том, что они вместе не стремились стать популярными, дав простой ответ на популярные вопросы.
                                            Вместо этого выстраивали логичный principled путь решения реальных проблем, а не быстрого проникновения в сердце прохожего интересующегося."


                                            Так вот, для того, чтобы выстроить логичный principled путь решения реальных проблем в PLT требовались многие годы, так же как и Haskell для того, чтобы стать production ready языком требовалось 15 лет. Это очень сильно отличает его от того же JS, который задизайнили за неделю, выпустили на свет как есть, а дальше строго берегли обратную совместимость. Но именно поэтому JS сейчас на коне, а Haskell есть там, где он есть. JS вышел на рынок и пусть крайне посредственно, но дал инструмент для решения задачи, которая без него никак до этого не решалась. Haskell стал production языком только через 15 лет после своего появления, когда все ниши уже заняты, а проблемы хоть и крайне отвратно и хрупко, но решены.


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


                                            Какой вы можете назвать общеизвестный проект, который написан на вашем любимом Хаскеле? У какого ФП-языка экосистема хотя бы приблизилась к объему C/C++/Java/JS?

                                            Мы уже кажется выяснили, что ФП не популярен. Что вы этим хотели сказать совершенно непонятно.

                                              0
                                              >Зайдем с другой стороны.

                                              Ну давайте. Еще с одной, если не против.

                                              А что у нас вообще популярно? Отвечаю не думая — web у нас популярен. А что такое web? Это javascript, так как де-факто на сегодня писать на чем-то другом уже можно, но пока еще сильно неудобно.

                                              >ФП-языки так не популярны
                                              Ну вот а теперь, попробуйте мне ответить, почему вы думаете, что ФП не популярно в среде javascript-еров? Да, это язык не чисто функциональный, побочные эффекты налицо, но в тоже время, функция есть сущность первого класса, функции высшего порядка возможны, и если чего нет — так это по большому счету системы типов.

                                              При этом многие части функциональной парадигмы не просто популярны, а давно популярны. Тот же пресловутый jquery с его $ — это в значительной степени функциональная идея (я видел как утверждения, что это монада, так и опровержения). И таких библиотек, в которых некоторые части ФП давно и успешно применяются — их полно. map, fold, reduce — так просто на каждом углу.

                                              И это не 10 лет назад было, наоборот, это прямо сейчас такая тенденция.

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

                                              Вам видится, что ФП не популярно? Мне пока видится ровно наоборот, как и тенденции.
                                                0

                                                То, что стало можно передать функцию в качестве параметра — это еще не ФП, а лишь элементы ФП. Да, многие языки переняли некоторые идеи ФП для удобства использования в определенных операциях, но при этом весь основной дизайн приложения остается в ООП и императивной парадигме. В частности, упомянутый filter/map/fold используется теперь как инструмент работы с коллекциями, и на нем в большинстве случаев и заканчивается весь перенятый ФП. И это нормально, когда в языки портируют наиболее интересные идеи, использование которых будет оправдано в определенных кейсах. Но ФП далеко не серебряная пуля, как заявляет автор и другие приверженцы, и сильно усложняет дизайн приложения например там, где появляется мутабельный стейт (например база данных — здесь ФП наполняется императивными хаками ввиде IO/do), или там, где необходимо моделирование сущностей/свойств и их отношений.


                                                Вам видится, что ФП не популярно? Мне пока видится ровно наоборот, как и тенденции.

                                                Если следовать всем тенденциям, то и блокчейн непременно должен быть в каждом пылесосе и утюге. :) О причинах непопулярности pure-ФП языков сказал предыдущий оратор в треде.

                                                  0
                                                  Если бы ФП было в javascript везде — я бы так и сказал, что оно уже захватило мир :) Да, пока это фрагменты.

                                                  И я вам так скажу — на мой взгляд, ФП именно таким образом станет популярным — путем интеграции интересных идей туда, где они приносят пользу. И этот процесс мне кажется как раз и идет.
                                            +1
                                            >До сих пор индустриальный стандарт в банковской системе, а специалисты по нему наиболее высокооплачиваемые. Но не суть.

                                            Эх. Люблю я эту тему. Знаете, я уже 10 лет в этой самой «банковской системе», и что характерно — ни разу не видел кобола. Как впрочем и хаскеля. Может про кобол — это уже давно легенда?
                                              0

                                              Я тоже думал легенда, но вот нет. Американские и некоторые европейские банки до сих пор используют процессинг на коболе, и вроде как менять не собираются. У нас в компании в банковском департаменте до сих пор сидят коболисты и что-то делают. Рынок, конечно, ограниченный, но время от времени всплывают предложения для кобола.

                                              0
                                              Знаете, я не могу считать скалу академическим языком. Вот раньше мог, а сегодня после Spark — не могу, и все. Может когда-то и был, а сегодня это чистой воды промышленное программирование, вполне себе ежедневное. Даже при том, что в нашем отделе, например, любители скалы и сторонники Java 8 делятся где-то пополам, в лучшем случае, т.е. позиции Java на сегодня более сильны. Но при этом и те и другие пользуются Spark, из которого уши скалы торчат буквально там и тут ;)
                                                –1

                                                К скале у меня особое отношение — я ее вообще не считаю ее за язык, мне жалко людей, которые на ней пишут, и также жалко тех, которые потом будут поддерживать этот код.


                                                Скала — это именно академический язык, помойка, в которую Одерски жадно набросал все, что только можно из других языков программирования в надежде, что это привлечет рыбех всевозможного калибра. Во времена застоя джавы он начал сильно форсить скалу как улучшенную джаву (потом, правда диаметрально поменял свое мнение, говоря, что скала — это совершенно другой язык), и на этот крючок попалось много компаний и разрабов (в т.ч. и я). Основным профитом заявлялась возможность при помощи системы типов писать DSL-и для предметной области. Но что-то как-то не сильно взлетело. Язык оказался сложным, громоздким, медленным в компиляции, трудночитаемым, не таким интероперабельным с Java, а также проблемным в совместимости с собственными версиями. Код зачастую превращался в мультипарадигменное месиво, которое было сложно контролировать (причем парадокс: те, кто только осваивал скалу писали лучший код, чем те, кто уже что-то на ней умел). Early-adopters вцелом оставались недовольными и зачастую переписывали свой стек обратно на Java. А тут еще Java 8 с лямбдами подоспела, что вызвало массовый обратный отток разрабов. Те же, кого не устраивала Java уже активно смотрели в сторону Котлина, который ехидно заявлял, что не ставит целью соперничать со скалой. В конце-концов, Одерски понял свою ошибку, но время уже было упущено.


                                                Фактически единственной областью, где скала зарекомендовала себя — это потоковая обработка данных, и то во-многом благодаря сложившимся обстоятельствам в виде Akka. Чувствуя долгожданный профит, Одерски с друзьями запиливает Typesafe (ныне Lightbend), куда сваливает все необходимое для законченного решения.


                                                Ну и как бы что Spark? У него есть удобоваримый Java-интерфейс. Да, написан на скале. С таким же успехом он мог бы быть написан на Java/Kotlin/Groovy.

                                                  0
                                                  А можно цифры? Сколько вот это вот «массовый отток»? 2? 3 человека? Просто так цифрами кидаться — быть Львом Толстым. Чувствуется ваша личная неприязнь (которая имеет место быть, мы живем в мире, где каждый имеет свое мнение), которая выдается за мнение большой группы людей, при этом пруфоф нет. И спасибо за вашу жалость =)
                                                    –1
                                                    >Ну и как бы что Spark?
                                                    Да ничего спарк. Вот представьте себе, совершенно реальный ежедневный use case: аналитики, а не программисты, лезут в Spark Shell, и пишут там скрипты. Не, они не сами это придумали, это я их научил, если честно. Но: Spark Shell это Scala Repl, просто в чистом незамутненном виде, с двумя или тремя переменными в контексте от спарка.

                                                    То есть, люди ежедневно пишут на скале, при этом не испытывая каких-либо неудобств. И им совершенно пофиг, что вам их жалко :)

                                                    Ну то есть, что описанные вами недостатки имеют место — я соглашусь без вопросов. Но однако же спарк меняет все дело, потому что это рабочая лошадь современной BigData, и он попутно делает скалу вполне промышленным языком, а не академическим экспериментом.

                                                    >С таким же успехом он мог бы быть написан на Java/Kotlin/Groovy.
                                                    Вот когда напишут — тогда и поговорим. Что на груви большого написали? gradle? Я так подозреваю (хоть я и не измерял, конечно), что он в разы меньше спарка по размеру кода. И в те же разы проще.
                                              0
                                              >многие ФП-языки не типизированные со всеми вытекающими проблемами
                                              Не, ну вы что, серьезно? Ну да, кложа не типизирована. Но система типов хаскеля одна из наиболее развитых вообще, скала типизирована, ML и F# тоже.

                                              И я бы на сегодня скорее сказал, что широко распространенный не-ФП язык Java скорее имеет «все вытекающие проблемы» из-за некоторых исторически сложившихся слабостей системы типов.
                                                0
                                                В бизнес приложениях фукциональный подход нисколько не хуже императивного. А насчёт простоты — есть пример 1С. Они сделали систему, которую должен может (по-идее) настраивать каждый бухгалтер. Там и язык русский, и уровень входа низкий… Но, таких бухгалтеров всё равно нашлось считанные единицы. И появились 1С-программисты, как жизненно необходимый для предприятия ресурс. Со временем, система усложнялась, бухгалтера уже отреклись от программирования, но язык остался таким же. Да, в 1С можно быстро создать бизнес приложение, но сопровождение типовых конфигураций превратилось в ад. Как вам процедуры/функции на тысячи строк?
                                                  0

                                                  А при чем тут ФП? Функциональная композиция из тысячи и одной однострочных функций только усугубит ситуацию, и работники не дождутся своей зарплаты. И опять же, я не против ФП-подхода, и использования его элементов там, где это оправдано. Я против рекламы функциональных языков как неотменного атрибута программерской элиты, и создаваемым ею карго-культом ФП, хотя реально область задач для него сильно ограничена.

                                                –1

                                                deleted

                                                  +2
                                                  Функции, которые принимают функциональные аргументы, называются функциями или функционалами высшего порядка.

                                                  Нет. Функционал — это функция с числовой областью значений.


                                                  Самым популярным функционалом является карта. карта, которая применяет некоторую функцию ко всем элементам списка, формируя другой список из результатов.

                                                  Морская или игральная карта? Map — это глагол, означающий "отобразить". Собственно и аргументом у неё является функция-отображение.

                                                    –1
                                                    Джойстик на последнем фото судя по всему BMW, очень глючный на практике оказался, т.е. показывать его как пример хорошего решения не очень правильно.
                                                      0
                                                      У меня есть большая и сложная модель из десятков тысяч объектов. Я хочу внести в нее некие пробные изменения и узнать как эти изменения повлияют на целевую функцию, потом новую порцию изменений и так далее. В функциональном стиле функция, которая вносит пробные изменения должна возвращать новую версию этой модели, но с изменениями. Учитывая что модель очень сложная (еще и формируется лениво), это задача невероятно сложная и в любом случае очень тормозящая работу.
                                                      Конкретно в этой задаче заменил на чистые максимально возможное количество функций. Код стал понятнее, это правда.
                                                        –3

                                                        Даже если бы я действительно был "должен" думать о ФП, я мог бы думать так: "Оно мне надо?"
                                                        Как религия — точно нет. Как увлечение — не зацепило то, что о нём знаю. Как инструмент — не вижу столько пользы, сколько затратится на смену парадигмы. Время-то утекает, и мне больше нравится расти в глубину, чем в ширину, утилизируя освоенное, а не отбрасывая.
                                                        Я выбрал путь и стою на нём. А ФП? Забавная штука, полезная к месту… Но вот не должен я ему ничего, и всё тут.

                                                          +1
                                                          Композиция функций — это подход функционального программирования, который включает в себя вызов одних функций в качестве аргументов других для создания сложной композиции из более простых функций.

                                                          Всё-таки, это относится к ФВП, а композиция, это применение функции к результату выполнения другой функции.
                                                          А статья нужная, хоть и несколько сумбурная :)
                                                            0
                                                            Самым популярным функционалом является карта.

                                                            Это .map(x=>y) так перевели?
                                                              0
                                                              Ну, а что же еще? Текст да, страдает местами.
                                                                0

                                                                Ага. Вдобавок, это к тому же не функционал.

                                                                0
                                                                Вопрос к фанатам ФП:
                                                                есть ли полноценный язык реализующий концепцию языка UnLambda?
                                                                  0

                                                                  А что вы имеете в виду под концепцией? Насколько я могу судить, Unlambda — это базовые примитивы ФП, которые есть что в Хаскеле, что в Scheme.

                                                                  0
                                                                  Спасибо большое, очень познавательная статья. Скажите, а есть какая литература по функциональному программированию?
                                                                    0
                                                                    Как пример:
                                                                    Scala
                                                                    Профессиональное
                                                                    программирование З-е издание
                                                                    ISBN 978-5-496-02951-3

                                                                    Книги по Java 8 +…

                                                                      0
                                                                      Спасибо большое за сведения
                                                                      0

                                                                      Любая книга о Haskell

                                                                        0
                                                                        Спасибо большое за сведения

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое