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

    image

    Привет! Меня зовут Катерина, и я испытываю самые тёплые чувства к функциональному программированию, использую функциональный язык на постоянной основе и даже немного преподаю.

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

    Как ФП улучшает программирование


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

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

    1. Код станет более лаконичным и выразительным. «Выразительность» можно определить как количество идей на единицу кода, и в целом функциональные языки, будучи более высокоуровневыми, оказываются и более выразительными. Например, преобразование каждого элемента в массиве или списке реализуется функциональным однострочником (используя map/foreach/whatever и анонимную функцию), в то время как в императивном стиле пришлось бы организовывать цикл, объявлять переменную для счётчика или итератора и использовать явное присваивание. Для более сложных примеров различие в выразительности только усиливается.
    2. Декомпозиция кода будет происходить более естественно. Принцип «Разделяй и властвуй» уже прочно закрепился в разработке и является базовым принципом борьбы со сложностью ПО. Речь идёт не о способе построения алгоритмов, а о более общем понятии. Например, даже простую программу, которая сначала читает целиком текст, разбивает его на слова и что-то делает с каждым словом, можно разбить на логические части: само чтение, разбиение прочитанного текста на слова (например, по пробелам) и создание структуры для хранения слов, обход этой структуры с преобразованием слов и печать результата. Каждое из этих действий можно реализовать отдельно и достаточно абстрактно, чтобы затем переиспользовать для решения других подобных задач. Декомпозиция кода на более мелкие и более общие части делает его гораздо более понятным (в том числе и для самого автора кода в будущем), позволяет избежать «ошибок копипаста» и упрощает дальнейший рефакторинг. Думаю, многим разработчикам приходилось копаться в своей или чужой простыне неструктурированного кода, написанного наспех, чтобы скорее заработало. Человеческому мозгу тяжело удерживать внимание на большом количестве сущностей одновременно и решать одну глобальную задачу сразу (working memory), поэтому для нас вполне естественно разбивать задачи на более мелкие, решать их по отдельности и комбинировать результат. В функциональном программировании эти мелкие задачи выражаются как небольшие вспомогательные функции, каждая из которых делает своё дело и её работу можно описать одним коротким предложением. А построение итогового результата — это композиция таких функций. Конечно, разбить код на отдельные переиспользуемые части можно и в ООП, и в чисто императивном низкоуровневом языке типа C, и для этого уже есть известные принципы типа SOLID и GoF-паттерны, но, когда сам язык заставляет программиста думать в терминах функций, декомпозиция кода происходит гораздо более естественно.

    3. Побочные эффекты будут отделены от чистых функций. Чистая функция — это функция в математическом смысле, результат работы которой зависит только от входных данных. В ходе вычисления такой функции не происходит ничего лишнего: не меняются значения переменных, ничего не читается и не печатается, не пишется в БД и не выполняются запросы к внешним сервисам. Действительно, вы же не будете ожидать таких действий от, скажем, тригонометрических функций? С помощью чистых функций можно реализовать большую часть логики работы с данными. Не все языки позволяют контролировать отсутствие побочных эффектов и проверять «чистоту» функций, но сам по себе функциональный подход мотивирует использовать чистые функции, которые работают «без неожиданностей».
    4. Код станет проще отлаживать и тестировать. Этот пункт вытекает из двух предыдущих: у нас имеется набор небольших функций, часть из которых чистые, т.е. мы знаем, что их результат зависит только от входных данных. Код становится удобнее отлаживать — достаточно проверить, что возвращают используемые функции по отдельности, чтобы понять, как они будут работать вместе. Так же легко пишутся юнит-тесты для «чистой» логики вашего приложения. 

    Как ФП улучшает программиста





    Далее мне хотелось бы поделиться своим опытом, не относящимся непосредственно к написанию программ на функциональных языках, и рассказать про то, чем ещё знание и использование ФП было полезно для меня и может оказаться полезным для вас:

    1. Изучение альтернативной парадигмы само по себе полезно для мозга, поскольку в процессе освоения программирования в функциональном стиле вы научитесь смотреть на привычные вещи по-другому. Кому-то такой способ мышления покажется гораздо более естественным, чем императивный. Можно долго спорить о том, что «нужно» и «не нужно» в индустриальном программировании, но там в любом случае нужны хорошие мозги, а их нужно тренировать. Осваивайте то, что не используете в работе: Лиспы, Пролог, Haskell, Brainfuck, Piet. Это поможет расширить кругозор и может стать для вас увлекательной головоломкой. Со временем вы сможете начать применять более элегантные решения в функциональном стиле, даже если пишете на императивном языке.
    2. За функциональными языками стоит серьёзная теория, которая тоже может стать частью ваших увлечений или даже исследований, если вы в той или иной степени хотите связать свою жизнь с computer science. Учиться никогда не поздно, особенно когда перед вами будут наглядные примеры использования довольно занятной теории для решения повседневных задач. Я бы никогда не подумала, что уже после окончания университета буду смотреть лекции по теории категорий, которую мой мозг когда-то отказывался воспринимать, и решать задачки из курса ручкой на бумаге, просто потому что мне это интересно.
    3. Помимо расширения кругозора увлечение ФП поможет вам расширить и круг общения. Возможно, за «тусовкой функциональщиков» закрепилась репутация академических снобов, которые спрашивают у вас определение монады перед тем, как продолжить общение. Я тоже так раньше думала, пока меня не вытащили на первые функциональные митапы и конференции. Я была совсем неопытным джуном и не знала определение монады, но не встретила по отношению к себе никакого негатива. Напротив, я познакомилась с интересными людьми, увлечёнными своим делом и готовыми делиться опытом, рассказывать и объяснять. Разумеется, в любом комьюнити есть совершенно разные люди, кто-то вам понравится больше, кто-то покажется токсичным и отталкивающим, и это совершенно нормально. Гораздо важнее то, что у вас появится возможность обмениваться идеями с теми, кто смотрит на мир разработки немного иначе и обладает другим опытом.
    4. Самый неожиданный для меня пункт: мне было легче всего найти работу именно на Haskell! На данный момент мой опыт работы чуть больше пяти лет, за это время на двух из трёх местах работы я писала на Haskell, и это был наиболее комфортный и безболезненный опыт трудоустройства. Более того, начинала я тоже с позиции Haskell-разработчика, о чём ни разу не пожалела. На первой работе я получила базовые навыки клиент-серверной разработки и работы с БД. Мы занимались такими же «приземлёнными» и «ненаучными» задачами, как и компании, использующие более распространённые языки. На популярных сайтах с вакансиями вы, скорее всего, почти не найдёте ничего по запросу «Haskell-разработчик». В лучшем случае найдутся вакансии, где указано, что знание альтернативных парадигм будет преимуществом. Однако, это не значит, что таких вакансий нет. В Твиттере и тематических каналах в Телеграме вакансии появляются регулярно. Да, их мало, нужно знать, где искать, но и хороших специалистов такого узкого профиля тоже немного. Разумеется, вас не возьмут сразу и везде, но свою востребованность вы почувствуете значительно сильнее, чем при поиске работы на более распространённых языках. Возможно, компании могут быть готовы вкладываться в развитие программистов в нужном направлении: не можешь найти хаскелиста — вырасти его сам! 

    Заключение


    Появление элементов ФП в популярных языках индустриальной разработки, таких как Python, C++, Kotlin, Swift и т.д., подтверждает, что этот подход действительно полезен и обладает сильными сторонами. Применение функционального стиля позволяет получить более надёжный код, который проще разбивать на части, обобщать и тестировать, независимо от языка программирования. Разумеется, функциональный язык позволяет использовать все перечисленные преимущества по максимуму, предоставляя естественные конструкции с высокой степенью выразительности.

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

    В заключение хочу пожелать всем не бояться использовать альтернативные подходы и пробовать их в деле, даже если это будет полезно исключительно для вашего саморазвития.
    Typeable
    Functional programming, High assurance, Consulting

    Comments 50

      +1
      В свое время решал, какой функциональный язык выбрать для продакшена для задач, где нет требований к low latency.
      F# победил с большим отрывом от всех.
      Прошло несколько лет, лишь убедился в верности своего выбора.
        +2
        >F# победил с большим отрывом от всех.
        а можно краткое пояснение причин? Чем он лучше haskell, scala? Вы пишите на F# промышленный код? Интересно узнать именно с точки зрения готовности для прода.
        +5
        Интересный язык Haskell, на этом сайте есть десятки статей, в которых обьясняется почему это самый лучший язык программирования и почему фенкциональное программирование лучше чем ооп, но нет ни одной статьи в которой бы разбиралось создание хоть чего то что используется в реальном мире.
          +1

          Я когда-то писала небольшой туториал по парсерам (https://habr.com/ru/post/436234/), вполне себе прикладная задача. Да и по запросу "haskell туториал" тут находятся посты. Но русскоязычных материалов в целом мало, это факт.

            +2

            Если без технических подробностей, то мы недавно про Octopod рассказывали, он тоже на Haskell: https://habr.com/ru/company/typeable/blog/541430/

              +10
              Есть все-таки. Когда-то (в 2011?) я описывал, как применял Хаскель для обработки телефонного трафика. Были еще и другие статьи про опыт использования его в проде. Конечно же, полно и других статей разного толка.

              Но на Хабр уже почти нет смысла писать. Я, например, пишу сразу на английском, потому что основная аудитория там. Я даже книгу написал про «building real world applications in Haskell»: Functional Design and Architecture. Причем подходы из книги я применил на практике аж несколько раз и с большим успехом. Так что мы про все это пишем, просто не на Хабр.
                +2
                Большое спасибо за книгу! Приобрел себе на leanpub больше полугода назад. Всячески рекомендую книгу по архитектуре — т.к. содержит конкретные и емкие примеры без лишнего словоблудия.
                Мне разве что местами не хватало последовательных шагов. В целом превосходная книга и своих денег стоит. Стоит поддержать автора рублем.

                Скажу честно дал паре человек почитать и они потом купили свои экземпляры книги.
                  +4
                  Здорово! Спасибо за добрые слова!

                  Давать друзьям — это нормально, я не против. Я вам больше скажу, она и на торрентах уже тоже есть, и я не собираюсь как-либо это ограничивать. На книгах все равно не заработать, так что пусть люди читают хотя бы так.
                +2

                Если вы ещё не используете ShellCheck, то...

              • UFO just landed and posted this here
                  –3
                  Ну конечно же стоит!
                  Вакаснии есть? Платят норм? Работа проще чем классическая ООП разработка?

                  Ничего не имею против ФП и даже планирую полистать хаскель как-нибудь на досуге, но вот какая проблема: статьи о том, какое ФП прекрасное, я читаю каждый месяц. Статьей о том, как ФП поможет мне заработать на BMW 7 серии я не видел еще ни одной.
                  • UFO just landed and posted this here
                      –3
                      Есть: нам грамотный эрлангист или эликсирщик позарез нужен
                      То есть целая одна вакансия да и та, на которую нужен не вчера перекатившийся с ООП, а сразу сеньёр-помидор.

                      (Понятно, что есть еще вакансии, но мы-то понимаем их исчезающе мало по сравнению с классической разработкой)

                      А чёрт его знает…
                      Без понятия
                      Это весьма невоодушевляющие ответы на вопрос «зачем перекатываться в ФП» знаете ли.
                      • UFO just landed and posted this here
                          –1
                          Ну не перекатывайтесь, никто ж не заставляет.
                          Ну смотрите, вы сначала говорите что «конечно же стоит вести разработку в функциональном стиле», а потом на вопрос «зачем?» отвечаете «не хотите — не ведите».

                          Такая себе аргументация.
                          • UFO just landed and posted this here
                              0
                              И вопроса «зачем?», кстати, не было. Были вопросы про вакансии, зарплату и как оно в сравнении с ООП.
                              Мне буквоедство неинтересно, извините.
                              • UFO just landed and posted this here
                                • UFO just landed and posted this here
                        +2
                        >Статьей о том, как ФП поможет мне заработать на BMW 7 серии я не видел еще ни одной.
                        Есть классическая статья Пола, о том как они создали viaweb, которая потом была продана Yahoo за что-то типа $50 миллионов. Вся эта статья просто пропитана духом того, как именно Lisp позволил им этого добиться. Старая статья, очень старая…

                        Сколько там BMW 7 серии можно было купить за $50 миллионов, не подскажете?
                          0
                          В районе 1500 штук.

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

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

                              А по-моему так программированием вообще очень редко зарабатывают достаточно большие деньги.
                              Вопрос не в больших деньгах как таковых. Вопрос в том, какой смысл программисту на ООП переходить на ФП? Денег больше? Работа проще? Проекты балдежнее? Еще что-то?
                                0

                                Смотря что программист хочет от жизни и что ему интересно. Если он работает с 9 до 5, и ему пофиг, на чём писать, все инструменты одинаково хороши — то это всё неважно.


                                Если программисту важна корректность и выразительность языка — смысл есть. Ну и проекты балдёжнее, да (но это, опять же, ИМХО, все балдеют от разного).

                              +1

                              По 33 000 за штуку? Таких цен уже 20 лет как нет

                            +2
                            Вакаснии есть? Платят норм?

                            Вполне. Был не так давно оффер, который был лишь процентов на 5 ниже оффера в хардкорный HFT на плюсах (и который сам по себе был сильно выше рынка).


                            Работа проще чем классическая ООП разработка?

                            Зависит. Я вот специально ищу поинтереснее — например, чтобы надо было что-то там формально доказывать. Это, думаю, тяжелее классической ООП разработки.

                          +1
                          No offence, просто в статье про «сильные стороны» неплохо было бы перечислить и слабые. Топ-3, на мой взгляд:
                          1. Тезис Чёрча является доказанно-недоказуемым. Т.е. нам предлагается поверить, что произвольную ФП-программу в принципе можно скомпилировать в нечто более-менее выполняющееся на реальном железе. Дать оценку времени выполнения ФП-программы хотя бы в О-нотации в общем случае нельзя.
                          2. На практике, в мейнстримные языки действительно завезли элементы ФП, только вот банальный немодный явный цикл for выполняется в разы и на порядки быстрее, чем аналогичный map-reduce. Возможно, это недоработка компиляторов, но что есть то есть.
                          3. Лямбда-исчисление (все эти ваши монады с каррингом) требует нетривиальной математической подготовки, которой у обычных инженеров, как правило, нет. И, в отличие от конечных автоматов или там реляционной алгебры, «просто почитать книжку» не получится. А без этого код на ФП предвращается в шаманство и магию (ну, примерно как паттерны проектирования:). Это значит, что хороших ФП-программистов тупо мало (ну, в разы меньше, чем хороших «императивщиков»). А это приговор с точки зрения бизнеса.
                            +5
                            Тезис Чёрча является доказанно-недоказуемым. Т.е. нам предлагается поверить, что произвольную ФП-программу в принципе можно скомпилировать в нечто более-менее выполняющееся на реальном железе.

                            А то, что машин Тьюринга на практике не существует и не может существовать, вас не смущает?


                            Дать оценку времени выполнения ФП-программы хотя бы в О-нотации в общем случае нельзя.

                            Это верно только для ленивого ФП. Впрочем, я последнее время добавляю {-# LANGUAGE Strict #-} почти всегда и нахаляву получаю профиты энергичного ФП, оставляя ленивость только тогда, когда она действительно нужна для семантики.


                            На практике, в мейнстримные языки действительно завезли элементы ФП, только вот банальный немодный явный цикл for выполняется в разы и на порядки быстрее, чем аналогичный map-reduce. Возможно, это недоработка компиляторов, но что есть то есть.

                            Какой язык? Какой компилятор?


                            В этом моём хаскеле компилятор может слить несколько mapов и fold* подряд, не аллоцируя промежуточные структуры данных и оставляя данные для последовательных применений разных функций в кэше. Как с этим у for?


                            Лямбда-исчисление (все эти ваши монады с каррингом) требует нетривиальной математической подготовки, которой у обычных инженеров, как правило, нет.

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


                            И, в отличие от конечных автоматов или там реляционной алгебры, «просто почитать книжку» не получится.

                            Блин, а у меня получилось. ЧЯДНТ?

                              0
                              А то, что машин Тьюринга на практике не существует и не может существовать, вас не смущает?

                              Нет, не смущает, потому что единственное невыполнимое ограничение — бесконечная память. Сейчас у каждого в кармане ~1012 этой самой памяти, не бесконечность, но достаточно близко. Самое главное, что мы знаем, какие алгоритмы относятся к неполиномиальным (коммивояжер, SAT — печально, но некритично), а всё остальное без проблем реализуется.
                              Какой язык? Какой компилятор?

                              Да любой из мейнстримных, от плюсов до js. Для функционального кода они сегодня в лучшем случае умеют хвостовую рекурсию (но это неточно), тогда как для императивного фигачат векторные инструкции только в путь.
                              Блин, а у меня получилось. ЧЯДНТ?

                              Мы это года три как поняли, предлагаю не переходить на личности). Списки вакансий по языкам вполне однозначны.
                                +3
                                Да любой из мейнстримных, от плюсов до js. Для функционального кода они сегодня в лучшем случае умеют хвостовую рекурсию (но это неточно), тогда как для императивного фигачат векторные инструкции только в путь.

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

                                  0
                                  Первая ссылка в гугле, тыц: habr.com/ru/post/516034
                                  брать языки, не заточенные под задачу

                                  Языки сегодня берут не под задачу, а под команду.
                                  И да, именно из-за незаточенности я написал дисклеймер:
                                  Возможно, это недоработка компиляторов, но что есть то есть
                              +3

                              Ну, к примеру, Rust (пусть он далеко не функциональный) может оптимизировать и ераторы, все эти map и reduce до уровня zero-cost abstraction, не такая в производитеьбности (не всегда). Был где-то хороший пример с обработкой звука, но сейчас не смог найти.

                            0
                            ФП может и вправду так хорошо, но…
                            Мне пока хватило видео Соера «Как функциональное программирование портит программистов на JavaScript», хоть и не JS-программист, но понимаю о чём он говорит.
                              +2

                              Как программирование в парадигме, не свойственной языку, портит программистов на этом языке? Ну, это довольно простой вопрос.

                                0

                                Видео не смотрел, но JS не очень-то ООП-ный язык. Я бы сказал он к функциональщине ближе.

                                  0
                                  Тем что нет тех же железобетонных правил и ограничений «чистых ФП-языков», когда шаг вправо-влево, расстрел компилятором на месте.
                                  И соответственно разработчик волен либо сам костылить монады/каррирование и прочее, либо брать библиотеку и полагаться на «стороннее видение»*. А потом приходит js-джуниор и «пишет как умеет».

                                  И по итогу у большинства там будет не «надежное ФП», а «функциональный цирк».

                                  *тут из личного опыта могу вспомнить милые попытки скрестить lodash с TypeScript и «радости» от того что какой-нибудь compose с огромным удовольствием терял типы где-то внутри себя, порождая на выходе any.
                                +4
                                Я могу понять как какая-то Джава работает в энтерпрайзе: всевозможные варианты «провалидировать форму, положить в базу» настолько там проработаны, все шишки сообществом уже набиты и искать что-то другое для решения задачи смысла нет.

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

                                С Хаскеллем у меня ощущение, что это «от идеалистов и для идеалистов». Все статьи о том, как на Хаскелле удобно работать, демонстрируют решение каких то абстрактных задач в вакууме. Из моего опыта с Хаскеллем — я пытался написать raytracing на этом ЯП, убил вечер, и даже запустил. Но когда я попытался ускорить то узнал что либа, которую я взял для рендеринга изображений, не поддерживает параллелизацию — так что весь смысл чистоты ФП оказался спущенным в мусорку самими разработчиками либы (которая всплывает в верхних результатах выдачи гугла). А переписать под другую либу оказалось сложно, потому что, внезапно, ей требуются совершенно другие данные, в другом формате, и весь процесс рендеринга у неё выглядит по-другому.

                                При этом, да, у меня есть знакомый со своей фирмой, где все запросы клиентов решают только на Хаскелле. Бизнес-модель работает: этот код никто больше кроме них не может понять или отредактировать, таким образом получается vendor-lock совершенно минимальными ресурсами, а рекламу им делают, в том числе и такие стати о преимуществах и крутости Хаскелля над другими языками, особенно которые ОО.

                                Но я это пишу к тому, что если уж и учить что-то новое, то для себя я лучше разберусь в том, как кешируются данные в Hibernate, поковыряю документацию и внутренности PostgreeSQL или разберусь с OpenShift'ом, вместо того что бы разбирать что такое монада и зачем нужен функтор. А за других могу только порадоваться — если вам платят за работу на Хаскелле, то я только за, я вообще за то, что бы все могли заниматься тем, что любят, и получать за это достойную оплату.
                                  0
                                  Но я это пишу к тому, что если уж и учить что-то новое, то для себя я лучше разберусь в том, как кешируются данные в Hibernate
                                  я занимаюсь проектом на java, немного знаю haskell. С уверенностью могу сказать, что мне проще разобраться как работает какой-нибудь persistent или slick, чем hibernate.
                                  Многие требуют какой-то невероятной подготовленности к production для новых/непривычных инструментов. При это на сырость привычных инструментов закрывают глаза.
                                  Будь моя воля, как разработчика на java — я бы никогда hibernate в production не пропустил. Т.к. это библиотека, как не парадоксально, для него не готова. И, судя по всему, не будет готова никогда =)
                                  +1
                                  Играл немного с F#, любопытная штука. Пара мелких заметок по ходу, положу комментарием.

                                  Функциональное программирование требует отсутствия побочных эффектов (side effects). Собственно, это не является корневым требованием, корневое это ссылочная прозрачность (referential transparency). Но отсутствие побочных эффектов является необходимым следствием. Возможно даже, необходимым и достаточным, тут нужно подумать-почитать. Разумеется, полностью избавиться от побочных эффектов невозможно. Потому что побочные эффекты это то, ради чего мы программируем. Изображение на дисплее, звук, запись в файл, передача данных по сети — всё это побочные эффекты. Программа без них была бы вещью в себе, не взаимодействующей с внешним миром. И в этом, как мне представляется, проблема функционального программирования. Оно требует извращённого выверта мозга, при котором ты перестаёшь видеть свою цель и считать её целью. А в самом конце приходится идти на лицемерный финт, нарушая красоту и благолепие, потому что мы, святые люди, всё ещё не вполне в нирване и не можем отринуть до конца потребности грешного тела. Альбигойская ересь какая-то: это ведь они считали, что духовный мир создан Богом, а материальный — Сатаной.

                                  ***

                                  Очень хвалят F#, функциональный язык программирования под .NET Framework. Начал про него почитывать. Нужно сказать, что в родном объектно-ориентированном C# уже давно появились кое-какие функциональные элементы: LINQ, лямбды. Что там, лямбды уже и в C++ есть. Поэтому F# не шокирует с первого взгляда. Да, и так можно. Так короче, возможно — надёжнее. Чуть медленнее работает, но нам не привыкать платить производительностью. Нам есть чем платить, современные компьютеры на редкость мощные дуры. Не понятно для бизнеса, вот это уже серьёзнее. Идея «код должен быть понятен бизнес-аналитику» встречается всё чаще. Собственно, это частный случай более общей проблемы: ООП разрабатывалось как средство моделирования реального мира. Функциональное программирование реализует абстрактное «хорошо» не привязанное ни к чему. Эта концепция рискует оказаться чем-то вроде эсперанто: всё вроде бы правильно, а культурного багажа нет, говорят редкие энтузиасты.
                                  Впрочем, это моё незрелое мнение. Продолжаем погружение.
                                    +1
                                    Собственно, это частный случай более общей проблемы: ООП разрабатывалось как средство моделирования реального мира.

                                    Где вы в реальном мире видели фабрики фабрик?

                                      0
                                      Несомненно, что сейчас ООП используется не только для моделирования объектов реального мира. Но фабрики фабрик как паттерн появились много позже ООП. В оригинале же, на всяких старых курсах, ООП учили именно на объектах реального мира.
                                    +1
                                    Функциональное программирование требует отсутствия побочных эффектов (side effects)… побочные эффекты это то, ради чего мы программируем.

                                    Вы, конечно, правы, но на самом деле всё наоборот.

                                    Это популярное заблуждение, что в чистых языках или в ФП нет побочных эффектов.

                                    В «грязных» языках побочные эффекты разрешены в любом месте и ими нельзя управлять. В чистых языках побочные эффекты живут только в специальных объектах-загончиках, только там, где они нужны, и ими можно управлять.
                                    0

                                    Подскажите, какие паттерны вы используете для коммуникации между слоями в коде и внедрения зависимостей?

                                      +1

                                      Из моего опыта — стек mtl-трансформеров и Service Handle паттерн, который пробуем сейчас на проекте.

                                        0

                                        Монады и их обобщение на тайпклассы (не обязательно в mtl-стиле) просто шикарны для DI. Такой DI и компилятор, считайте, проверяет.

                                        +1

                                        Haskell, конечно, крут. Я его практически не знаю (только начал изучать), но он мне уже нравится. Но проблемка одна есть — ни разу не видел вакансии типа "junior haskeller". Везде либо требуется опыт 100500 лет, либо "мы тут пишем на всяком г… не, но будет бонусом, если вы вдруг знаете Haskell зачем-то".

                                          0
                                          Большинство опытных хаскелистов получились как раз на таких местах, где надо совмещать г и Хаскель.
                                          +3

                                          Есть прикольная книжка на пару вечеров https://www.ohaskell.guide

                                          Only users with full accounts can post comments. Log in, please.