Pull to refresh

Comments 9

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

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

Интересная статья, спасибо за труд. Все мы знаем, что реализовать функциональщину можно на любом языке, тем не менее хотелось бы видеть какой-нибудь Haskell, а не JS. Ну и отмечу кое-что важное, что я не увидел (а может проглядел), дело не в надёжном коде. Одна из основных сутей функционального программирования (что вы делали на протяжении всего кода не явно) - неизменяемые переменные. Это позволяет избежать множества проблем - дедлоки, гонки и все т. п. В заточенных под ФП языках такого нет или имеет крайне ограниченный функционал.

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

Я уверен, что этот человек программирует на haskell.

Если мы продолжим использовать эти структуры достаточно часто, то привыкнем к ним

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

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

Хотя да, что-то в этом есть, но "что-то" есть и в альтернативных подходах. Может им и уделить то самое время, которое требуется на "использовать эти структуры достаточно часто"?

А с другой стороны над нами стоят сроки. Вот и выбираем локальный оптимум.

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

В коммерческих проектах чаще всего не ООП непреложная данность, а фантазии на тему - типа папка Controllers и условные IOrderService. Так и сейчас от фп используют условные лямбды да вариации на тему Future ?‍♂️

Хорошая статья. Однако мало кто задается вопросом, а почему ООП стал стандартом разработки? Можкт стоит упомянуть о недостатках функциональщины?... К вопросу о популярности ООП и ФП. В 2013 в ИТМО поиезжал с Страуструп. Я был на той встрече и один из студентов спросил его, насколько популярен язык Хаскел и каково будущее ФП. На что Страуструп слегка задумался и с улыбочкой ответил: "ну, я знаю пару ребят, которые пишут на Хаскел" :))))

Справедливости ради, а что мог на такой вопрос ответить Страуструп? Нашли кого спросить про ФП :)

А теперь к добавим к этому всему НОРМАЛЬНЫЙ синтаксис, и будет счастье.

Sign up to leave a comment.

Articles