ага, его книга классная (жаль что в 8 много чего уже не так)

А конкретнее можно? Хотелось бы разобраться.

ну например Functor -> Applicative -> Monad

Некоторое время назад я задавал тут вопросы по методу рамды "chain", долго пытаясь понять его суть. И хотя тогда благодаря ответам тут я ее уяснил, но сейчас мне попалась статья где сей метод описывается вообще наглядно и "на пальцах" ) http://buzzdecafe.github.io/2016/12/29/chain-chain-chain Это я на всякий случай, вдруг кому понадобится ) Но вообще там и другие статьи тоже толковые.

Ну дык

Это автор рамды

Кстати, рамда, судя по их кукбуку https://github.com/ramda/ramda/wiki/Cookbook пропагандирует строго "функциональный подход" на счет того что б не сохранять в константах промежуточные данные. Во всех примерах они оперируют ТОЛЬКО ФУНКЦИЯМИ. Это, на мой взгляд, уменьшает читабельность кода (хотя может я это говорю с непривычки). Есть ли преимущество у такого подхода? Я полюбил рамду из-за возможностей разного рода пайпов/компосов и прочего. Но в своем коде я обычно по преждему использовал константы с промежуточными значениями. А есть ли преимущества от отказа от сохранения промежуточных значений, и манипулирования только лишь функциями?

Кстати, рамда, судя по их кукбуку https://github.com/ramda/ramda/wiki/Cookbook пропагандирует строго "функциональный подход" на счет того что б не сохранять в константах промежуточные данные. Во всех примерах они оперируют ТОЛЬКО ФУНКЦИЯМИ. Это, на мой взгляд, уменьшает читабельность кода (хотя может я это говорю с непривычки). Есть ли преимущество у такого подхода? Я полюбил рамду из-за возможностей разного рода пайпов/компосов и прочего. Но в своем коде я обычно по преждему использовал константы с промежуточными значениями. А есть ли преимущества от отказа от сохранения промежуточных значений, и манипулирования только лишь функциями?

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

Ну конкретно композ - это частный случай ) Я вообще о том, есть ли преимущество от использования в качестве констант ТОЛЬКО функций?

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

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

Ну конкретно композ - это частный случай ) Я вообще о том, есть ли преимущество от использования в качестве констант ТОЛЬКО функций?

есть

нет переменных, нет мутаций

збс

А я не про переменные говорил, а про константы ) А мутаций ты и в пайпах наделать можешь

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

Всё проходит с опытом

А я не про переменные говорил, а про константы ) А мутаций ты и в пайпах наделать можешь

константы мутабельны тоже

Ну так или иначе, функциональный подход (через рамда) не защищает от мутаций

это джаваскрипт

конечно, ты можешь стрелять себе в ногу

и в голову тоже

но без переменных что ты в пайпе мутировать будешь?

конечно, ты можешь стрелять себе в ногу

Вот потому я и спрашиваю, есть ли в js преимущества от использования ТОЛЬКО ЛИШЬ функций в качестве промежуточных значений?

я и говорю

но без переменных что ты в пайпе мутировать будешь?

Переданный в пайп объект

Рамда поддерживает мутации

без перменных ты не можешь их мутировать

ты копируешь и передаешь след функции

можно сделать сайдэффект, но так не надо делать

ты копируешь и передаешь след функции

Но операции над объектом в рамде бывают и мутабельными

бывают

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

Это не дает никакой защиты

ща мб для кого-нибудь срыв покровов будет

http://ideone.com/VtEkwK

Кстати, рамда, судя по их кукбуку https://github.com/ramda/ramda/wiki/Cookbook пропагандирует строго "функциональный подход" на счет того что б не сохранять в константах промежуточные данные. Во всех примерах они оперируют ТОЛЬКО ФУНКЦИЯМИ. Это, на мой взгляд, уменьшает читабельность кода (хотя может я это говорю с непривычки). Есть ли преимущество у такого подхода? Я полюбил рамду из-за возможностей разного рода пайпов/компосов и прочего. Но в своем коде я обычно по преждему использовал константы с промежуточными значениями. А есть ли преимущества от отказа от сохранения промежуточных значений, и манипулирования только лишь функциями?

Отказ от переменных ради отказа от переменных не нужен, если проще написать с ними — пиши, это ок) Стиль рамды позволяет абстрагироваться от конкретных объектов и описывать операции в общем виде, в универсальной и краткой форме

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

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

А попытаться сразу писать point-free-everything — это прямой путь к fp fatigue, сколько раз уже наблюдал подобное ?

?

я часто пишу с с лямбдами а потом просто смотрю к чему можно применить PF

А попытаться сразу писать point-free-everything — это прямой путь к fp fatigue, сколько раз уже наблюдал подобное ?

ага, это про меня в том числе) давно перестал так делать

доброго дня ( вечера) уважаемые пользователи

привет

В первом конде, правда, ошибся и забыл вытащить val в первом действии.

Сойдёт) Вместо () => true в рамде есть T, а вместо проверки в первом cond есть propEq

Сойдёт) Вместо () => true в рамде есть T, а вместо проверки в первом cond есть propEq

А то что 2-ой cond не чистый, не является антипаттерном?

Если честно, то я бы вообще назвал использование cond с одной провкеркой антипаттерном ?

Это очень утрированный пример. Главный вопрос в том, нормально ли замыкать переменные извне или лучше делать хэндлеры в cond чистыми?

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

йо йо

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

лооол

это троллинг?

не, у меня немного времени не хватает

в джава-конфе забанили?

еще в чатик реакта скинь вакансию по ангуляру)

ээ

может у него RxJava

ага, может у них там редакс и фетч без rx

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

Только зачем там фп - непонятно.

Есть же няшная Скала.

Только зачем там фп - непонятно.

А где фп уместно?

ERROR: S client not available

Есть же няшная Скала.

Не все могут сменить язык

А где фп уместно?

Не в языках, где все заточено под ООП.

да в жаве особо под ооп не заточено(

Тогда надо добавлять в описание группы и жаву, лол.

Тогда надо добавлять в описание группы и жаву, лол.

В описании все фп-релейтед языки?)

Нет, там библиотеки.

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

Вообще немного напрягает, что нет чистого ООП языка, когда чистый ФП есть. ?

Вообще немного напрягает, что нет чистого ООП языка, когда чистый ФП есть. ?

Смолтолк

Ну его всегда приводят в пример. Да и язык он вполне интересный. Правда ещё уместна мысль что классы лишняя сущность при описании объектов. Тут не знаю какой язык привести в пример

js )

Тогда надо добавлять в описание группы и жаву, лол.

описание ограничено в символах)

js )

Примитивы есть же, которые не объект.

Или это некритично?

некритично. красиво когда они объекты, но в целом на решение твоих проблем это не скажется

https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html - лямда в жаве кстати уже есть.

js )

так до сих пор и не вник в прототипы. чувство, что не много потерял и что все на них кладут.

так до сих пор и не вник в прототипы. чувство, что не много потерял и что все на них кладут.

Это наверное критически важно для понимания механизма языка, а на практике редко встречается.

Я сейчас реализовал две штуки — callable classes (классы, у которых инстанс — функция) и классы, чьи инстансы создаются без new, короче пришлось вникнуть в прототипы

Могу заверить что без них ваще ничего не теряете))

Нудно и кроме таких эдж кейсов уже не особо полезно

Сойдёт) Вместо () => true в рамде есть T, а вместо проверки в первом cond есть propEq

А если хочу проверить вот так: propEq('prop', true), есть более короткий аналог, но чтобы именно true, false проверить?

А если хочу проверить вот так: propEq('prop', true), есть более короткий аналог, но чтобы именно true, false проверить?

нет

А если хочу проверить вот так: propEq('prop', true), есть более короткий аналог, но чтобы именно true, false проверить?

propIs(_, Boolean)

propIs(_, Boolean)

ну это на тип проверка

а не на true

А, ну да, не так прочитал)

Ему тогда надо составить требуемые однострочники для проверки

Если это конечно оправдано)) Потому что проверка на true false самая короткая по записи в жс

Там кстати новая версия рамды вышла, если кто не видел)

Добавили mergeDeep* в разных вариациях, startsWith, innerJoin и убойный o