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

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

@user-ex9zs4zv3e

3 жыл бұрын

Тоже удивился, почему разговор о ФП начался с каррирования, а не с "ссылочной прозрачности". В общем, немного спорные рассуждения у товарища Соера, "ФП плохо потому что в js сообществе его мало понимают", так там и ООП не понимают, большенство разработчиков пишут просто "влоб", им что ФП, что ООП -- один хрен :) Да и кто в здравом уме щас будет писать что-то новое на чистом js, когда есть Flow/TS/Elm и тд. где и типы и иммутабельность?

@aleksandercross5936

3 жыл бұрын

Выглядит правдоподобно, я в это верю

@optislav

3 жыл бұрын

Озвучил мои мысли, спасибо!

@user-si7he1kz9o

3 жыл бұрын

Покалеченным ООП и в особенности js, нужно еще дорасти до ФП. Гуглим "Object-Oriented Programming - The Trillion Dollar Disaster" и недаром в go все эти глупости урезаны до минимума

@feoktant

3 жыл бұрын

В Скале есть карирование. Не такое как в Хаскеле, обрезанное, но есть

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

@lmarloe

3 жыл бұрын

Да в опрос надо было добавить такой пункт

@paleface_brother

3 жыл бұрын

Это добавление в блюдо соуса "карри".

@olezhonnv3215

3 жыл бұрын

Да! И им лучше этого не знать! Не нужно оно им, свою штуку баксов заработают и без этого. Даже 2.

@user-vu6hn4ul2i

3 жыл бұрын

@@olezhonnv3215 в вашем комментарии прослеживается некая надменность. И, на мой взгляд, она не имеет под собой оснований.

@paulsheldon8199

3 жыл бұрын

@@olezhonnv3215 у нас в Киеве и 10 можно

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

@kaksisve4012

3 жыл бұрын

@@albertkagarmanov2141 паттерн MTL (monad-typeclass-lift) из одноимённой библиотеки для Haskell, как вариант. Но я не думаю, что в JS будут упарываться с монадными трансформерами. Плюс, MTL пытается решить проблему, созданную самим ФП. Программисту нужно описывать вычисления с несколькими эффектами сразу (ввод-вывод + случайные значения + обработка ошибок + ...).

@slavus54

3 жыл бұрын

Ещё довольно эффективно комбинировать парадигмы исходя из конкретных технологий экосистемы js, например в React в компонентах использовать функциональный подход, а на native писать в ОПП стиле следуя паттернам и принципам SOLID

@denyzhirkov

3 жыл бұрын

Ой всё.

@SerafimArts

3 жыл бұрын

Учитывая то, что и ООП и ФП для разных вещей вообще существуют. Одно про архитектуру, а другое про вычисления/алгоритмы. Ваш кэп (с)

@whitehat-it-4096

3 жыл бұрын

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

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

@enkryp

3 жыл бұрын

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

@stepanmereutsa8444

3 жыл бұрын

@@enkryp он начал говорить о том, что все понимают по разному из-за того, что возможности есть, но они опциональны

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

@user-yb3vy2wx8u

3 жыл бұрын

если правильно затипизировать реализацию curry в ramda, то tsc вешается практически на любой функции, чья сигнатура сложнее (a: number, b: number) => number

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

@isfland

2 жыл бұрын

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

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

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

@maxa8836

3 жыл бұрын

Жарящий гренки не может стоить 500 тысяч в месяц, а вот изготовляющий крутон - может

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

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

@UnrealSPh

3 жыл бұрын

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

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

@S0ERDEVS

3 жыл бұрын

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

@S0ERDEVS

3 жыл бұрын

Ссылка от Тимура: github.com/HowProgrammingWorks/EventEmitter/blob/master/JavaScript/9-min.js

@TimurShemsedinov

3 жыл бұрын

@@S0ERDEVS как тебе код? Красиво, кратко, но отладить или модифицировать че-то сложновато)

@TimurShemsedinov

3 жыл бұрын

@@S0ERDEVS ну вот вот если синтаксис композиции лучше подходит для выразительности и везде в проекте цепочки асинхронных функций или трансформаций даных в таком синтаксисе и он описан и понятен с примерами, то почему нет?

@konstantinneihardt1477

3 жыл бұрын

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

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

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

@unslaadkrosis3237

3 жыл бұрын

а я вот вероятно не так давно и многие видео действительно фрустрируют...

@cafedead

3 жыл бұрын

@@unslaadkrosis3237 Боюсь, если придете на собеседование, и начнете рассказывать о каррировании, вас никуда на работу не возьмут...)) Так что гоните эти мысли подальше...)

@unslaadkrosis3237

3 жыл бұрын

@@cafedead я ж не враг себе без прямого вопроса рассказывать про то, в чём не разбираюсь. Хотя бывает ляпнешь что-то сдуру, а за это зацепятся - вот ты упомянул про *** расскажи-ка что такое и зачем нужно :D

@artem_doronin

3 жыл бұрын

это про меня. Когда он говорит "это очевидно, это понятно" мне хочется плакать. Потому что мне не то, что смысл не понятен, я даже половины его профессиональных определений не понимаю)))

А может наоборот? Не стоит тянуть ООП в JS?

@sergiyshatunov3873

3 жыл бұрын

Синтаксис в ООП стиле очень даже удобен в некоторых ситуациях, я бы такой в erlang добавил.

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

@KOHCEPBNPOBAHHbIN_AHAHAC

3 жыл бұрын

В точку

@magomedmycaev7080

3 жыл бұрын

Я нашел книгу про алгоритмы, на телеграмм канале @bofre. В интернете эта книга стоит больше пяти тысяч

@nurgisazhumashev1275

3 жыл бұрын

Тоже самое🤣

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

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

@MechanicalFreaks

3 жыл бұрын

Примерно никак не отличается, когда проект большой - там уже различия стираются

@artemsokolov5007

3 жыл бұрын

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

@shalidor1619

2 жыл бұрын

@@artemsokolov5007 Будто мысля в терминах объектов, методов и мутирование не думаешь в терминах функций, дататайпов и прочего

@artemsokolov5007

2 жыл бұрын

@@shalidor1619 думаешь но во вторую очередь. если в первую - то пробелм нет. суть в том что огромному количесву кодеров так сильно вбили в головы ооп что для них сначала все через призму ООП идет а потом уже все остальное, это если остальное есть. и это часто накладывает сильные искажения на решения

@shalidor1619

Жыл бұрын

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

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

@nikitaproit

3 жыл бұрын

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

@____Olga__

3 жыл бұрын

сколько времени изучали js до первого оффер(а)?

@nikitaproit

3 жыл бұрын

​@@____Olga__ около года. Но я изучал не только js. Ещё c, c++, python, php, c#, java, R, sql и некоторые другие языки. И соответственно к первой работе успешно прошел на вакансии с php, c#, java и js. Но стоит сказать, что в то время когда я устраивался на джуна требовалость знать достаточно много как минимум ООП, solid, стандартную библиотеку соответствующего языка, 1 фреймворк и уметь катить в прод.

@lego12239nn

3 жыл бұрын

@@nikitaproit > уметь катить в прод. Катить?

@ixplo

2 жыл бұрын

полностью согласен. Люблю ФП, но каррирование -- это что-то нечитаемое и бессмысленное в JS -- анти-паттерн.

Согласен, что прежде чем что-то применять нужно провести ритуал "анахуа" :)

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

@ixplo

2 жыл бұрын

плюсую. иммутабельность и однонаправленность чтения кода из ФП + оптимизации в сторону читабельности -- это то, что позволило моим проектам не скатываться в легаси, и облегчило и удешевило поддержку в разы. Можно ткнуть джуна в азы ФП -- и он через неделю начнёт писать хороший поддерживаемый код за копейки :)

Здравствуйте SOER. У меня к вам вопрос. Подскажите пожалуйста, с чего начать изучение математики, c каких разделов точнее. Может быть какие то книги конкретно. Я учусь на программиста. Математику очень любил, но она была еще в школьные годы. Поэтому озадачился с каких книг начать более грамотно и точечно🙏 И спасибо вам за канал!!

@ruslanvolovik2745

3 жыл бұрын

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

@imacoder3160

Жыл бұрын

как щас дела обстоят?

@goshana1987

Жыл бұрын

@@ruslanvolovik2745 очень полезный совет) я написал, что любил математику и просто хотел на счет литературы узнать. А начинать или не начинать сам решу как нибудь..))

@ruslanvolovik2745

Жыл бұрын

@@goshana1987 и как дела за год узнал что-то?

@goshana1987

Жыл бұрын

@@imacoder3160 выучился и в прошлом году устроился на первую работу. С третьего собеса вроде как. Желаю вам удачи тоже!

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

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

@kaksisve4012

3 жыл бұрын

В потом трёхчасовое видео про их трансформеры. :)

Зло - это умничать много на ютабе и холивары разводить.

@vitalylarichev1059

3 жыл бұрын

Зато он умничает, потому обладает знанием и опытом. А ты воняешь в комментах, потому что ни того, ни другого у тебя нет.

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

@lego12239nn

3 жыл бұрын

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

@kai3341

3 жыл бұрын

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

Привет. Играешь ли в какие нибудь игры на компьютере? Если да, то в какие? Как ты вообще к этому относишься? Что думаешь?)) Можешь на соер толксе рассказать :) Извини, вопрос не по теме видео, оно просто последнее вышло и думаю комментарии сейчас здесь в первую очередь будешь смотреть :D

Пришлось искать и изучать что такое каррирование

@yuriilukianovych8660

2 жыл бұрын

В точку)

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

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

@artemsokolov5007

3 жыл бұрын

еще в добавок спросить - какого именно полиморфизма? их как минимум 3 типа есть. параметрический, адхок и сабатйпинг

@ixplo

2 жыл бұрын

но ООП в js точно портит программистов, увы )

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

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

@sergiyshatunov3873

3 жыл бұрын

Как будто ООП и ФП друг другу противоречат. На самом деле ФП это частный случай ООП.

@user-yb3vy2wx8u

3 жыл бұрын

если про JS говорить, то ООП в нем гораздо более чужеродно, чем ФП

@user-hw8fj5hj9s

3 жыл бұрын

@@user-yb3vy2wx8u там вообще все кажется чужеродно .

@ixplo

2 жыл бұрын

@@user-yb3vy2wx8u согласен. не оч понимаю, зачем в js тащат чужеродный ООП :)

Жаль у Вас нет курса по ассемблеру, С, С++.

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

@hino2

3 жыл бұрын

Начинается с const f = function...

@dmytromilovanov9726

3 жыл бұрын

@@hino2 может ресурс подскажете?

@UnrealSPh

3 жыл бұрын

на гитхаб можете поискать репозитории где применяется функциональный яп (для примера возьмите F#).

@user-dn7qr7vs1h

3 жыл бұрын

@@UnrealSPh там скорее всего будет полуимперативный получистый код. Пусть уж сразу хаскель, чтоб как по учебнику.

@UnrealSPh

3 жыл бұрын

@@user-dn7qr7vs1h да. Согласен с вами. Просто мне кажется репозиториев для ознакомления на хаскель не так уж и много. Но я могу ошибаться. Сам как дотнетчик назвал f# только потому что это первое пришло в голову

Говорить о подобной проблеме ПОНИМАНИЯ функциональной, хорошо обоснованной парадигме, при том что формального определения ООП не существует, с учетом всех недостатков ООП, некорректно.ФП лучше хотя бы потому что его легче поддерживать в мелких и средних проектах(допустим до 100000 строк кода, очень условно), потому что нет ООП ловушек изменения данных, наследования и прочего, Почему я вообще их сравниваю? Идеи одной парадигмы прямо противостоят другой. П.С. Понимание работы HOF, в данном случае curry еще никому не мешало П.С.С Следует провести аналогичный опрос на каких идеях держится ООП(и о чудо, тоже никакого согласия)

@AndrewMansonNoperapon

3 жыл бұрын

Ваш ответ ни о чем просто потому, что озвученная проблема существует в узких рамках джаваскрипта. Не думаю, что даже в мелких проектах на нем функциональные приколы легче поддерживать. Если же уйти от джаваскрипта, то вы в какой-то степени правы, но тут я больше стою на позиции, кто что знает, тому то и легче поддерживать. Вам легче поддерживать функциональщину, а кому-то ООП со всеми его приколами. Все-таки функциональщина и ООП - просто разные способы мышления и восприятия решения проблемы. И если у кого-то мозг заточен на ООП, то вы его никогда не переубедите в простом разговоре, что функциональщина лучше просто потому, что ему ваше "проще" - сложнее. Впрочем, как и в реальной жизни, где любому здоровому человеку можно определенными воздействием сбить психологические настройки и превратить его в "би" или даже в "гомо", здесь примерно то же самое. Взять мозги адепта, развернуть на 180 градусов, провернуть нечетное количество раз и получите нормального специалиста, которому нет разницы как писать. Как захочет заказчик, так и напишет без всякого напряжения ментальных сил :-)

@romankocherezhchenko34

3 жыл бұрын

@@AndrewMansonNoperapon изначально мне показалось что автор мросто притянул тему видео за уши. Он прав, в целом, не нужно пихать в язык то что ему не свойственно

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

@matyev-hcuabg

3 жыл бұрын

Есть общепризнанные стандарты (такие как PSR), но они далеко не всегда и не везде применяются как есть, так как всегда в компании найдется кто то "умнее" и напишет свои.

Я даже вопрос не понял, который он там поднял :( Я и не погружался в фп полноценно, только слышал что есть ramda и некий fantasy land, это некая библиотека или концепция, но она такая специальная, что это как ещё один язык.

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

Соер) Давай больше асма, заходи с козырей...) жс конечно актуален, но он не стоит всех этих разговоров о каррировании, на мой скромный взгляд... Ну реально после твоего видео желающих стать программистами поубавилось. Избавляешься от молодых конкурентов?) УмнО...)

Отличный доклад но хочется чуть больше примеров )

Интересен ответ ExtremeCode, ждем-с

Интересно рассмотреть ФП в JS с точки зрения в производительности. Помню, где то видел доклад по фп в Go, и одним из доводов было то что фп дает достаточно большой overhead по ресурсам и минусов гораздо больше чем плюсов.

@corey4448

3 жыл бұрын

А фп вроде никогда и не было про производительность)

@dsedchenko

3 жыл бұрын

@@corey4448 в чем тогда его фишка? Зачем и когда его использовать (кроме случаев с упором в паралелизм)

@corey4448

3 жыл бұрын

@@dsedchenko вычисления для матана, декларативность, и прочее. Не везде стоит вопрос производительности.

@olezhonnv3215

3 жыл бұрын

А оно так и есть!

@vas_._sfer6157

3 жыл бұрын

У ФП нет проблем в производительности. Просто у большинства реализаций ФП есть проблема с оптимизаторами и так далее. Хороший ФП язык может дать оптимизатору очень много. А вот ФП в JS может быть и медленным. Может даже стоит его "компилировать" в процедурщину? p.s. Я не эксперт в JS

Ой, да ладно строить серьезного дядьку, видели мы тебя на подкасте :D P.S. видос топ

Замалчивание ошибки - это означает что всплывет она гораздо позже и найти концы будет сложнее. Странно почему ты считаешь, что ошибку в этом случаи надо замалчивать, тем более, что curry относится не к домену а скорее к какой-то низкоуровневой утилите, где всё должно быть максимально стабильно.

У автора видео претензия к называнию "функциональное программирование" и он в качестве основного вывода в конце видео просит делать в JS тоже самое, только "проговаривать", что это не совсем чистые функции и не совсем каррирование. То есть он не призывает отказаться от функционального стиля, а просит "проговаривать". Таким образом, название видео "функциональное программирование портит программистов на JavaScript" можно переименовать в "Отсутствие знаний по функциональному программированию портит программистов на JavaScript"

Не понял, как каррирование (имхо это бессмысленный анти-паттерн в js) так хитро подменило понятие функционального программирования. Умеренное ФП в js имхо прекрасно (иммутабельность + чистота функций). А каррирование в js -- это чьи-то больные фантазии.

Подскажите, как отвечать на вопрос: JavaScript это функциональный или ООП язык программирования? И почему

@user-hm1kc3zo9r

3 жыл бұрын

Мультипарадигменный)

@avejantzero9090

3 жыл бұрын

Он дивергент.

@andreyzhukov2821

3 жыл бұрын

Трансгендер)

@enkryp

3 жыл бұрын

Посылать в жопу. Потому что это ложная дихотомия - он и то и другое с одной стороны, а с другой - ни то, ни другое..

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

С ФП не работал. Все что об этом знаю - "Функциональное программирование накладывает ограничение на присваивание.". Читал немного об этой парадигме в книге, это стиль, не язык. Одни языки больше под него подходят, другие меньше. Все вкусное из F# приходит в C#. Штука нишевая, не для всех.

кидаю это видео друзьям функцинальщикам

@user-dn7qr7vs1h

3 жыл бұрын

Есть более простые способы поссориться с друзьями 😂

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

@rokoss

Жыл бұрын

Как ты сказал 😂 завтра тим Лиду буду рассказывать это

@AndrewMansonNoperapon

Жыл бұрын

@@rokoss Можешь и архитектору рассказать и еще какому-нибудь сеньору :-) Два года прошло, а ничего не изменилось, только майкрософту не нравится джаваскрипт, все пытается из него очередной си-шарп сделать, натягивая на него сверху тайпскрипт...

Строгая типизация спасёт нас. Однажды.

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

Лайк если тоже не понял половину слов Соера :)

Ну вообще JS и создан для того чтобы делать как попало. Впрочем как и плюсы. В JS любую проблему можно решить несколькими разными способами. Есть коллбеки, промисы, async/await, есть JQuery, React, Vue и т.д. можно смешивать ООП и функциональщину, можно просто все делать на глобальных функциях... можно писать говнокод высокой степени паршивости...

Какая парадигма в JS является основной?

@vvlkblkc

3 жыл бұрын

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

@olezhonnv3215

3 жыл бұрын

Спагетти парадигма!

@crutchmaster9637

3 жыл бұрын

Чик-чик и в продакшон.

@johnd1431

3 жыл бұрын

Изначально прототипно ориентированная парадигма

@crutchmaster9637

3 жыл бұрын

@@johnd1431 Это не парадигма. Это ООП на минималках.

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

Правильный ответ - Не функциональное программирование портит программистов на JavaScript, а JavaScript портит программистов.

лучший код - код которого нет

Я питонист ,что у вас там за херня происходит джаваскриптеры?

@jelooJusta

3 жыл бұрын

у нас все ок, пропсы прокидываем

@eugeneponomarov7429

3 жыл бұрын

Да все пытаются что-то навязать, хотя язык вроде как объектно ориентированный (объектно-прототипно ориентированный)

@user-nk6dl3kk7o

3 жыл бұрын

@@eugeneponomarov7429 жс мультипарадигменный

@UnrealSPh

3 жыл бұрын

@@user-nk6dl3kk7o да сейчас почти все модные языки - мультипарадигменные) чувак просто пытается сказать, что львиный уклон сделать в ООП в js через прототипы.

@ievgenk.8991

3 жыл бұрын

Привет, обьясни пожалуйста почему в консоль выводится 0 1 x = 0 y = 0 def f(): x = 1 y = 1 class C: print(x, y) # What does this print? x = 2 f()

Да ладно, улыбайся, мы всё знаем

Почему-то вспомнилось, даже не знаю почему? В программировании нет слова "НЕЛЬЗЯ" - kzread.info/dash/bejne/f316yJdwoNy1m7w.html&ab_channel=S0ERTALKS

Вопрос, ведь, не в том, тащить или не тащить в JS функциональное программирование, а в том, КАК рости в функционального программиста, когда душа требует, но без опыта в такие конторы не берут, а единственное, куда бедный вчерашний студент может устроиться, что бы было, что кушать и платить ипотеку - это на JavaScript-разраба... Как работая JS'ником, стать, например, Scala'истом?..

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

Частичное применение нельзя использовать вместо каррирования. Это как сказать: я предпочитаю заменять покупку пиццы на ее сьедение.

Лучший! Чистый рок'н'ролл)

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

@lego12239nn

3 жыл бұрын

> в наши дни многие люди начинают свой путь с изучения Реакта а не Жаваскрипта. Блин, я реально с таким одним общался. Это кошмар конечно.

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

@arvgo41

6 ай бұрын

Иди ты на хуй, на фронте давно реализован 3Д, и другие технологии о которых такие чайники как ты и другие бекендеры даже не слышали. А те задачи которые щас на ЯвуСкрипт возлагаются, далеко за пределами, по сложности, Фронта, и бекенда вместе взятых. Ищь бля обычная бекендерша будет тут судить о сложности, ну или кто ты там.

Я просто новичок: одни говорят ооп на джс зло другие сейчас фп на джс зло: так какой подход использовать?

@user-hw8fj5hj9s

3 жыл бұрын

Переходи на Питон .

В понятие чистых функций не входит такой параметр как иммутабельность. Главное чтобы функция ничего не трогала лишнего и вела себя предсказуемо. А в каком виде переменные будут передаваться вообще всё равно.

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

@UnrealSPh

3 жыл бұрын

вопрос ведь не только в терминологиях и "уровне знании". Здесь автор видео явно пытается указать, что природа ЯП влияет на то, можно ли использовать те или иные вещи или нет. Для примера возьмем инкапсуляцию в ООП: нет в js такого модификатора как private. А что это означает? Означает то, что вы не сможите ограничить пользователя вашего класса от вызова функции, которых он по идее вызывать не должен. Это приведет к неправильному использованию класса. Да, конечно, вы можете выдумать свою собственную "нотацию" и правила. Но вопрос, сколько людей будет этому следовать? А если вы делаете библиотеку для второй команды, с которыми вы не коммуницируете часто? Берете Java, C# и вы точно гарантируете что никто в ваш приватный метод не залезет. Потому что это ЯП поддерживает из коробки. P.S: конечно это все не избавляет от проблем криворукости, но суть сообщения не в "руках", а в том, что иногда лучше не натягивать сову на глобус

@abdullaevfarhad7884

3 жыл бұрын

@@UnrealSPh вот именно, что js не разрабатывался как чистый ООП язык со статической типизацией. Замечу, что язык создавался с оглядкой на scheme. Просто никто не обещал, что работать с js, да и вообще с любым ЯП - это легко. Поэтому я говорю, что нужно постоянно учится. К тому же замечу, что сейчас, судя по моему опыту, js уходит из большой коммерческой разработки, сильно сдавая позиции тайпскрипту. И криворукость тут совершенно не при чем, вообще, очень глупое слово, применительно к написанию кода. Получается, что все мы криворукие, потому что никто не застрахован от написания плохого кода.

Смотреть можно минимум в x 1.5 ускорении а так тема действительно интересная

Монады вполне можно применять в JS, например, для обработки ошибок (Either) и для цепочек вычислений, например трансформации потоков данных, вот цепочки Promise же прижились, а это влияние ФП тоже, но точно так же можно возвращать из функции массив [err, res], хотелось бы кортеж, но у нас на как замену кортежей только массивы есть )

@S0ERDEVS

3 жыл бұрын

Вопрос не возможности применения, а единообразного использования термина в рамках JS и сообщества.

@user-lj6it6kk1x

3 жыл бұрын

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

@TimurShemsedinov

3 жыл бұрын

@@S0ERDEVS ну так это вопрос образования и проникновения терминов в сообщество, в js с этим вообще больно, меня вот один человек спрашивает: подскажите, а почему я вот пишу-пишу, и что не напишу - все контроллер получается ))))

@TimurShemsedinov

3 жыл бұрын

@@user-lj6it6kk1x Ух, вот это вы задачку задали, я об этом лекцию на час могу сделать, а в двух словах и чтоб всем понятно. Да и вообще, эти термины тоже не вполне устоялись и могут пониматься разными людьми по-разному. Я предпочитаю называть функциональным объектом - значение функционально типа, к которому добавлены свойства и/или прототип, чтоб у него еще методы торяали, т.е. у него и вызов функции определен и еще и методы есть. А вот функтор - это уже контейнер функциональный, он должен удовлетворять математическим законам, которые на него люмбда-исчисление накладывает, для js это все адаптировано, написаны контракты и тесты, а табличку с разными функторами можно найти тут: github.com/fantasyland/fantasy-land

@S0ERDEVS

3 жыл бұрын

​@@TimurShemsedinov для меня это скорее вопрос практической пользы таких знаний. Ведь разработчики потом попадают в команды и работают над реальными проектами. И мне совсем не нравится тот результат, который получается.

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

@sergiyshatunov3873

3 жыл бұрын

На самом деле у функции есть 2 аргумента: arguments и this.

Обычный JavaScript разработчик будет долго рассуждать, выбирать один из четырёх вариантов опроса, а потом, столкнувшись с подобной ситуацией, молча сделает третий вариант, проигнорировав параметр b

А почему так завелось, что эксепшены так не популярны в js? Меньше срок поддержки и жизни приложений? Не критичная область применения? Лень или экстрасенсы и лучше знают, что может понадобится и разрулят любой расклад? :)

@dimeliora

3 жыл бұрын

Слабая система типов, движок в рантайме сам разрулит, как-нибудь))

@sergiyshatunov3873

3 жыл бұрын

Дело в том, что многие даже не знают что такое исключения и тем более не умеют их использовать.

@lego12239nn

3 жыл бұрын

@@sergiyshatunov3873 Да. Потому что начинают изучение с react, а не с js.

Короче, я показал это бизнесу, бизнес на меня наорал и уволил

@purplep3466

3 жыл бұрын

@Robert Sapolsky бузинесс

С чего это вдруг вызов вида (ab)(c) и (a)(b,c) неверное поведение? Функция каррированная должна поддерживать все варианты. Если вы хотите именно такое поведение, как вы описали в видео -- кидайте exception. А вообще согласен полностью. Каррированию нет места на проде в фронте

Я понял... Не надо тянуть чужеродные парадигмы... Иначе получится как всегда(

Описанная в видео проблема появляется от отсутствия статической типизации в JavaScript. Поэтому необходимо использовать TypeScript со статической типизацией везде, где это возможно. Тогда не придется даже задумываться о проблеме неправильного количества аргументов у функции!

@imyasuka

Жыл бұрын

Однако это видео о javascript и это не будет решением

тут больше не JS портит, а те кто не хотят париться и решают в лом текущую задачу ну или чуть подумав, для примера есть строка 'rflb' где f (forward)=(0, 1), b (backward)=(0, -1), l (left) = (-1, 0), r (right) = (1, 0) т.е. направления по координатам и решить ее можно разными способами от ООП до решения в лоб и "не в глаз а в бровь" типо подумав :) например const instructions = 'fflff' // [-1,4] // 1 подумав const f = c => instructions.split('').filter(v => v == c).length; [f('r') - f('l'), f('f') - f('b')]; // 2 через switch в лоб instructions.split('').reduce((pos, mov) => { switch(mov) { case 'f': pos[1] += 1; break; case 'b': pos[1] -= 1; break; case 'r': pos[0] += 1; break; case 'l': pos[0] -= 1; break; } return pos; }, [0, 0]); ну и куча других решений, только через ООП решать не будут так как долго, много писать, а тут быстро и делает то что нужно. Потом если нужно перепишем :). Большинству не нужно ООП, ведь это занимает много места (размер файла) и работает в итого медленно, да и можно и без наследования обойтись проще и быстрее создать новый объект студенты или преподаватель чем мучатся с наследованием. Typescript должен был решить эту проблему, но им тоже криво пользуются многие. Единственное что я вижу в JS это ставить типо eslint, findbug и т.п.. Чем больше ограничивающих правил и проверок будет тем чище и качественнее будет код. Хотя...

каррирование в js на мой взгляд это лишнее как и ооп и функциональщина в целом ))), js как и golang это вещь в себе, ты можешь перетянуть туда все что хочешь но весь вопрос зачем, а как же keep it simple, stupid )))

мда... странно слышать подобное от Евгения... что ж, дальше будет много букв, ибо если критиковать, то аргументированно. Начну с каррирования, уж не знаю почему на него делается такой акцент, притом не в первый раз уже. Основная претензия тут к некоторой реализации функции под именем curry, которая изначально появилась в библиотеке underscore (крайне далекой от ФП), потом была унаследована в lodash (изначально на 100% совместимой по интерфейсу с underscore), а после появившаяся еще и в ramda (ибо неудачное имя уже прижилось). И да, там ни что иное, как автоматическое частичное применение. Но как по мне, довод о некорректности некоего термина в некоторых популярных библиотеках вообще ничего не говорит о применимости некоторой парадигмы к некоторому языку. Далее нам в противовес приводят якобы автоматическое карирование на якобы истинных ФП языках, совершенно забывая при этом сказать, что в данных языках в принципе не бывает функций более чем от 1 аргумента, но их синтаксис позволяет с этим весьма комфортно работать. И кстати, данный синтаксис весьма непривычен для многих разработчиков, привыкших к си-подобному синтаксису. Чтоб было понятно, приведу пример на Haskell: f a b c = a b c Весьма лаконично. Полный аналог на JS будет выглядеть так: const f = a => b => c => a(b)(c); Уже не так лаконично, зато вполне наглядно, что никакой автоматики тут нет, просто особенности синтаксиса. Ок. Давайте пойдем дальше. Разберем следующую претензию, что якобы некоторые парадигмы в некоторых языках могут приводить к трудно поддерживаемому коду, к хаосу. Вот только это не зависит ни от парадигмы, ни от языка. Можно и в ООП устроить адок из наследования, можно в структурно-процедурной парадигме плодить лесенки из if'ов, можно в ФП нарушать ссылочную прозрачность или детерминизм. А можно прививать разработчикам культуру кодирования, благо инструментов для статического анализа сегодня много, как и возможностей по его автоматизации. В особо запущенных случаях можно применять радикальные меры, например CI может ревертить любой коммит, не прошедший линтер, лечит на раз, проверено, через неделю все пишут в едином стиле принятом в команде. Тут правда стоит оговориться, что у многих eslint стоит для галочки, поставят популярный дефолтный конфиг, а потом просто отключают, то что мешает жить... Действительно настроить eslint умеют единицы, а на нормальных фронтопс бизнес пока не готов тратить деньги. А зря, ведь eslint решает все перечисленные выше проблемы. Дальше. Чистота функций и каким то боком притянутая сюда иммутабельность. Иммутабельность вообще относится к ФП примерно так же, как наследование к ООП - никак. Ну разве что и то и то неплохо сочетается вместе. Но если кто не в курсе, наследование придумано на 2 года раньше ООП. А ФП прекрасно живет без иммутабельности, сохраняя чистоту функций. Если что, данная функция чистая: function f(arr) { let result = []; for(let i = 0; i result.push(arr[i] * 2); } return result; } Зато вот эта вполне иммутабельная функция имеет эффект: const f = () => Math.random() * 10; Но даже она вполне себе может жить в ФП коде, если сместить ее выполнение на край, в "грязный" рантайм фреймворка. В заключение хочу лишь сказать, что заблуждения встречаются абсолютно у всех разработчиков, независимо от опыта, используемого языка или парадигмы. А так же хочу заметить, что вся прелесть мультипарадигменных языков, в том, что они позволяют комбинировать полезные приемы из разных парадигм.

@sergiyshatunov3873

3 жыл бұрын

Отличие каррирования в Haskell и JS в том, что кортежи в Haskell содержат фиксированное количество элементов, тогда как arguments в JS - массивоподобный объект произвольного размера. Это в некотором смысле каррирование даже упрощает. Не надо заводить отдельное каррирование для каждого числа аргументов. Ещё одним значимым фактором является this. По сути в Haskell у функции всегда один аргумент, тогда как в JS есть как arguments, так и this. Во многих случаях this не используется и игнорируется. Однако это важная часть языка. При комбинировании функций важно предполагать что результат может использоваться в качестве метода. Почему автор придолбался именно к каррированию вообще непонятно. Функциональных комбинаторов огромное множество и каррирование из них не самое востребованное на практике. Одной из ниш, в которой применимы функциональные комбинаторы является быстрая смена API. Новое API реализуется на базе предыдущего, при этом новые методы и типы данных - результат операций над предыдущей версией. Когда результат прошел тесты и работает корректно, тогда можно рефакторить и избавляться от комбинаторов если это улучшит наглядность кода. Для подобных целей я использую этот набор github.com/Svoloch/etc-js/blob/master/function.coffee

На мой взгляд, приход ФП в любой язык это показатель прогресса, того что сообщество ищет и самое главное применяет лучшие паттерны. ФП заставляет тебя мыслить более высокими абстракциями, а это приводит к более понятному коду. Да, чтобы понимать ФП нужно знать его постулаты, но ведь с ООП аналогично. Проведите опрос среди JS разработчиков о контексте и скорее всего результат будет похожим. Если делать плохо, то оно и будет так. Про тесты тоже стоит вспомнить. Не писать же процедурщину на С.

@sergiyshatunov3873

3 жыл бұрын

На JS тоже можно писать процедурщину, и многие так делают. Ну а что касается понятия "контекст", так оно может означать что угодно, иногда this, иногда scope, иногда совсем другое. Так что прежде чем употреблять этот термин надо согласовать его значение.

@lego12239nn

3 жыл бұрын

> На мой взгляд, приход ФП в любой язык это показатель прогресса, того что сообщество ищет и самое главное применяет лучшие паттерны. Нет. А вот то, что человек употребляет слово "паттерны" значит, что он не понимает о чём речь ;-). > ФП заставляет тебя мыслить более высокими абстракциями, а это приводит к более понятному коду. Вообще нет. Дело не в абстракциях. И если мы уходим от академического кода в сторону производственных реалий, то это приводит к более НЕпонятному коду на практике.

@Iaxls

3 жыл бұрын

@@lego12239nn хорошо)

Исходя из того, что язык динамический и очень быстро развивается, разная поддержка окружающими средами, то вариант f3c(a,b)(c) === f3c(a,b,c) выглядит более логичным, так как разработчики пытаются в том же стиле расширить поддержку для других разработчиков как делают это транспайлеры

@lego12239nn

3 жыл бұрын

Ну вот как можно так написать, что ничего не понятно?.. Что за транспайлеры? Нафига это нужно - f3c(a,b)(c)? Чем f3c(a, b, c) не угодил?

Пока не появится хоть один игровой движок на фп уровня Godot хотя бы, фп так и будет сосать у ооп.

я только-только начинаю изучать JS, сразу глянул в учебнике про каррирование и нашёл верный ответ :|

Модно, классно, свежо - это вообще бич разработки на жс имхо. По теме, опять же на правах имхо, решение должно быть максимально очевидным. Если на проекте есть люди, которые не понимают подход/реализацию, то стоит либо подтянуть общий уровень, либо наступить на горло собственной песне и писать "для тупых" (вот тут вероятно особо умные ребята начинают скучать и думают о смене проекта), либо (вспоминая видео с Линусом Торвальдсом) - какого хрена такие бездари делают в нашей команде?

@ievgenk.8991

3 жыл бұрын

Стадию "модно, классно, свежо" проходят или проходили все мейнстримовые, зрелые технологии.

@ixplo

2 жыл бұрын

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

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

Я за первый вариант, где 20%. Для js самое то! Варианты с эксепшном и игнором параметра категорически не поддерживаю! В ФП я - если не полный 0, то может 0.01. Не сказал бы, что не шарю от слова совсем. Ну, я знаю, что оно есть, что такое чистая функция или функция высшего порядка. В общих чертах. Считаю, что слишком много вокруг него шумихи в мире js. Намного больше, чем оно того заслуживает. Именно в мире js, учитывая, для чего этот язык используется.

сложнА. Ни лайкнуть, ни дизлайнуть))) Если мой первый язык JS - это излечимо? Есть ли какой то смысл упоминать алгоритмическую парадигму в контексте других парадигм? Парадигма = мироопись = язык ведения описи мира = язык ведения инвентарных списков? Каков внутрений диалог прогера как терминахтера при думании о переносе, проэкции с одной парадигмы на другую?

@sysInt64

3 жыл бұрын

@Валерий Лис и что в этом плохого? вообще не важно какой первый язык.

@Mike-hp3fh

3 жыл бұрын

@Валерий Лис У меня первым языком был Basic на ZX-Spectrum, и это мне как-то не помешало выучить еще несколько и сменить несколько специализаций

ФП без системы типов - время на ветер. Описанна в ролике проблема, с нотацией типов - не может возникать

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

@ixplo

2 жыл бұрын

Полностью согласен и поддерживаю. Каррирование -- это какой-то нечитаемый и бессмысленный бред для JS. Как сделать проект сложнее и дороже в поддержке -- просто начните обмазываться паттернами из ООП или каррированием и монадами из ФП.

@shalidor1619

2 жыл бұрын

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

@ixplo

2 жыл бұрын

@@shalidor1619 вы понимаете, что сейчас необходимость одного паттерна объяснили необходимостью поддерживать ещё один? человек об этом и пишет, что на ровном месте мы обмазываемся усложнением кода, вместо того, чтобы просто делать последовательные понятные вызовы

@shalidor1619

Жыл бұрын

@@ixplo меньше кода + возможность юзать теоркат. Можно не усложнять, никто не заставляет. А вообще можно писать все в одном файле и в одной процедуре с goto. Тут уж на вкус и цвет. Мы всегда обмазываемся усложнением кода, когда юзаем те же абстрактные классы, дженерики и тп, только потом это вдруг оказывается очень полезным

Так какой там был правильный ответ? :)

@hino2

3 жыл бұрын

Первый

@egorselyanin9739

3 жыл бұрын

Правильный ответ в таких случаях - это читать доки к функции. Ибо поведение может зависеть от реализации в конкретной либе / проекте. Основная проблема - это сами скобочки. Поэтому в чисто функциональных языках часто используют вызов функций без скобок. foo a b c == (foo a) b c == (foo a b) c

@sergiyshatunov3873

3 жыл бұрын

@@egorselyanin9739 Именно поэтому я и использую CoffeeScript, надо меньше скобок.

Что значит халиварная?

@bl1tzQ

3 жыл бұрын

Бурное обсуждение, где каждый продвигает свою мысль

@kaksisve4012

3 жыл бұрын

От англ. "holy war".

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

Dzmitry Sidorov, а что же вы удалили все ваши чудесные инженерные аргументы про феерическую сложность фронтенда? Dzmitry Sidorov replied: "Vs Sm " в недостатке абстрактного мышления у большинства программистов." - хотели сказать, в недостатке архитектуры приложения? окей, определение

Lodash за первый вариант. И в этом есть смысл в плане удобства применения

@user-yb3vy2wx8u

3 жыл бұрын

и ramda тоже, а когда js/ts проект использует ФП, с большой вероятностью в зависимостях будет ramda

@shalidor1619

2 жыл бұрын

@@user-yb3vy2wx8u ramda если поиграться только, полноценное фп на ts можно лишь с fp-ts реализовать, либо тянуть кучу либ хз как хорошо связанных друг с другом по типу фолктейла и тп

@user-yb3vy2wx8u

2 жыл бұрын

@@shalidor1619 fp-ts - это кривая и тяжелая пародия на хаскель от людей, которые не понимают ни сути фп вообще ни хаскель в частности. Многие концепции хаскеля не реализуются нормально без HKT, коих в js/ts нет. В итоге в fp-ts куча тяжелых костылей, только ради того, чтобы это обойти и быть похожими на хаскель. Смысла в этом 0.

Я всё ещё не понял галдежа, потому что в чем смысл в функцию, задуманную как f(a)(b)(c), вызывать f(a,b)(c). Типо, разве это не оговаривается в команде и не обсуждается перед использованием? Кто в своем уме захочет просто взять, и передать неправильное количество параметров, зная, что может произойти какой-то обсёр? Это разве не то же самое, что в функцию, принимающую параметр строки запихнуть число и бомбить из-за того, что она не работает?

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

@user-ij5jn2xc4t

5 ай бұрын

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