Как функциональное программирование портит программистов на JavaScript

#soer #itubeteam

[emirisaev]

все мы знаем что лучшее каррирование это "Хочу посмотреть результаты"

[sharn]

54% просто не знают что такое каррирование

[artemsokolov]

0. каррирование это не ФП. в Scala нет каррирования, но там можно отличнейше писать в ФП стиле со всеми плюсами и практически без минусов и без неудобств. мне кажется пример каррирования изначально не правильный. лучше возьмите для примера лучшее из ФП и разберите на примерах плюсы и минусы, профит и стоимость их использования.
я бы первым взял иммутабельность и чистоту (Referential transparency) - это то что составляет основу профита ФП, кмк.
1. тезис про то что в ФП сложнее конструкции - ложный. они нерпивычные для средстатистического "вкатывальщика" - да. но возьмите человека который никогда не работал с ООП а работал с ФП и он точно также скажет что ООП это какая-то непонятная и сложная хрень. и при этом с другой стороны если взять ООП челика и дать ему изучить ФП - он будет уметь в ФП и для него все будет прозрачно и понятно.
2. "функция должна быть устойчива в неверному использованию" - это какая-то проф деформация из мира ЖСа походу. неверный ввод - давай отлуп. фаил фаст так сказать. зачем притягивать за уши какие-то попытки обработать всякую хрень - непонятно. вообще проверка должна быть на уровне типов - используйте флоу или ТС. но если статической проверки нет - должна быть динамическая. типа как в питоне. подсунул не верный тип данных - давай отлуп. эксепшены тут кстати тоже сильно не ФП механизм. возвращайте Either ошибка/результат. дальше вопрос насколько удобно будет с этим работать в ЖС, но интуиция подсказывает что нормально будет работать, особенно когда добавить сахара в язык под это через препроцессоры или в новом стандарте.
3. довольно недальновидно спрашивать у сообщества ЖСеров вопросы про ФП, потому-что 90+% из них не знают парадигмы и не умеют в ней работать. понятно что они дадут рандомные ответы.
4. рассуждения про различные варианты использования/стили и что это разброд и шатание. я не знаю какой стиль в ЖС сейчас доминирует. но с ООП будет тоже самое. все понимают принципы ооп по своему. и точно также все пишут по своему. и даже если возьмем не ООП а просто "как мы работаем с параметрами функции" то кто-то будет их валидировать, кто-то будет выкидывать лишние аргументы (умалчивать b как вы сказали), кто-то будет пытаться привести типы к ожидаемым (объект в строку и погнали), кто-то выкидывать эксепшн. чем ФП парадигма здесь отличается - не понятно. кажется ЖС настолько гибкий и не имеет ограничений, что там можно на любой парадигме писать десятками способов одни и те же вещи. почему при взгляде именно на ФП с этим появляются проблемы..?

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

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

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

[konstantinnaschekin]

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

[enkryp]

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

[vladimirkrasulya]

`не используйте ФП потому что вы его не понимаете` - ну все логично че )

[TimurShemsedinov]

Удел JavaScript - это мультипарадигменное программирование, JavaScript гибкий, как Assembler, мы создаем новые синтаксисы, впитывая идеи из всех парадигм, и делая синтаксис выразительным в конкретном случае. Я вот тебе подкину в копилку пример того, как ФП может сделать EventEmitter совершенно крутющим на первый взгляд, но соверженно диким и нечитаемым:

[whiteandy]

@S0ER, а что вы думаете насчёт функционального программирования на Typescript?

Исследуемая исключительная ситуация будет падать во время компиляции, если правильно затипизировать.

[eugenenovikov]

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

[romanbush]

Соер а как ты относишься к rxjs? (reative x) стоит или нет использовать, является ли это функциональным программированием, как такое дебажить?

[genjin]

Спасибо, Д'Артаньян за поучительное видео. Теперь я знаю что мне не желательно делать, но может поделишься с тем что приемлемо? В чем проблематика? Почему люди заимствуют паттерны из других подходов?

[cafedead]

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

[vasisafronov]

54% людей, такие как я, не имеют никакого опыта и заходят послушать умные слова от умных дядек)))

[nikitaproit]

Вопрос странно поставлен, т.к. написано буквально: Нужно ли делать "exception handling" при передаче лишних параметров в функцию?
И правильный ответ: нет не нужно.
Да и в принципе странно мерять ФП в js по функции которую в js не используют даже ярые фанаты ФП.
Программистов на JavaScript портят те кто принимает их на работу после курсов "JS за 30 секунд".

[travanchik]

если сравнить ФП с каким то запутанным императивным кодом, то ФП в большинстве своем будет приятней

[DubinArtur]

@Soer, Чем плох синтаксический сахар? Можешь рассказать своё видение?

[MrFallout]

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

[andreybergdev]

Крайне не корректный эксперимент. Для примера можешь провести такой-же эксперимент в контексте ООП, и спросить у аудитории является ли перегрузка функций проявлением полиморфизма? Результаты должны очень удивить, но это не является поводом заявлять что ООП портит программистов.

[eugeneponomarov]

Следующее видео:"Что такое монады?" - он же ещё такое не записывал?

[xhhwckz]

а какой % программистов используют 4-й универсальный вариант ?