У тебя в слове ПхП опечатка.

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

>>1099260 (OP)
>Но хуй знает, это хак или нет?

Использовать замыкания для решения архитектурных проблем - признак хренового ООП.

Использовать их или нет? Смотри на легаси которое придется переписывать.

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

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

yoba модуль нейм
Было:
> call(1,2,3,4,5)

Стало:
> func = config["func"] || DefaultFunc
> func.new(self).call(1,2,3,4,5)

>>1099260 (OP)
>Паттерны функционального программирования
Их не существует. Кроме того, любой разговор о каких-то там 'паттернах' в программировании - полная лажа.

>>1099337
>А в чем вообще главная идея функционального программирования?
http://fprog.ru/2009/issue1/eugene-kirpichov-fighting-mutable-state/

>>1099357

Бтв, утром продолбился в глаза про пфп (были же хаскель/эликсир etc треды). Ну тогда наверное да, замыкания.

>>1099367
Типичный случай парадокса Блаба. Знаешь, книги тоже пишут словами, однако же всякие завязки и кульминации там используются.

>>1099543

Паттерны в ооп параше, монады - в фукциональной.

>>1099337
Пошел нахуй.

>>1099357
>Использовать замыкания для решения архитектурных проблем - признак хренового ООП.
Люто двачую, потому и спрашиваю.

>>1099398
Бля, но ты в том посте про что-то другое написал. У меня проблема чисто архитектурная. Хуй с ними с замыканиями, это я обдолбался вчера. Проблема в том, что у меня древовидные зависимости между компонентами, но в одном месте компонент компонент надо передавать вниз, в обратном направлении. Специально для подобного у меня есть один кусок мутабельного состояния, но мне приходится пихать в него типа служебные данные (тот самый компонент, который вниз надо передавать), что как бы не очень красиво. А может и нормально, хз.

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

>>1099371
Прочитал.
Получается, что главная идея функционального программирования в отказе от мутабельных структур данных, т.е. иммутабленость ради иммутабельности?

>>1099862
> иммутабленость ради иммутабельности?
Вот когда-нибудь устроишься на работу, сделаешь пару проектов - тогда и поймешь, ради чего нужна иммутабельность, сириусли. Ну или не поймешь, если рефлексировать не будешь.

Серьезно, чувак, 2018 на дворе - об этом столько уже написано и сказано, что всерьез воспринимать такие вопросы крайне затруднительно. Не траль, пожалуйста.

>>1099260 (OP)
>>1099769

> древовидные зависимости между компонентами
> компонент компонент надо передавать вниз
> приходится пихать в него типа служебные данные

Я бы сделал наверное как:
1) Всю древовидную залупу обернул в сущность, которая предоставляет КОНТЕКСТ.
2) Сделал бы стороннюю функцию высшего порядка, которая умеет ТОЛЬКО доставать из КОНТЕКСТА некие значения, и перредавать их дочерним функциям
3) Юзал бы компоненты и в хуй не дул
4) Если компоненту нужен КОНТЕКСТ, я бы оборачивал его в ту самую херню из п2 и она бы предоставляла ему некое подмножество КОНТЕКСТА какими нибудь опциональными аргументами. Желательно чтоб компонент и без нее работал.

Это одно охуенно большое замыкание, да, но ключевое тут что оно ОДНО, и мало coupling. Компоненты работают сами по себе, контекстопредоставляющие хуйни сами по себе. Всем похуй друг на друга и все счастливы.

И да, если вдруг в контексте значится, что iDidNotFuckYourMom, это лишь значит, что он пиздит.

>>1099862
не, братан, не только. Мы просто хотим чтоб операции, которые нормальные люди выполняют за O(1), выполнялись за O(log n). Например, просто запросить данные :3

>>1099871
У меня примерно так и было, да. И примерно так и есть сейчас, с одним но: контекст и древовидная залупа - это разные сущности. Контекст - это, грубо говоря, один из компонентов залупы, просто без всякой логики. Там смотри в чем фишка, этот контекст (ссылка на него) нужен компоненту А, от которого зависят все другие компоненты. Но при этом другие компоненты могут добавлять в контекст свои хуевины, которые потом должны мочь использовать функции из компонента А. Ну то есть тут никак не получается контекст сделать иммутабельным, и это, конечно, хуево, потому что в идеале бы хотелось, чтобы компоненты могли в контекст сами пихать свои мутабельные штуки со своей семантикой. Ну разве что делать сложный лайфсайкл всем компонентам: сперва инит, в котором компонент А недоступен, но доступна уже инициализированная (другими компонентами) часть контекста. Инит возвращает новый контекст. А потом уже старт, в котором доступны и контекст, и компонент А (шина это короче, хуль я как дебил его "компонент А" называю, блядь). То есть порядок инициализации такой: контекст, все компоненты, шина. Хм, а "старт" вообще-то можно и не делать частью лайфсайкла - шина ж уже есть, можно тупо слать компонентам сообщение, и пусть они сами уже делают, если им что-то надо.

Блядь, чувак, вот спасибо, наконец-то сел спокойно на 2 минуты, подумал и написал.

>>1099873
>O(log n)
ДЛЯ n < 42!!!!11 ВСЕ РАВНО КОНСТАНТА!! МНЕ НИПИЧЕТ!!!!1111

Достопочтенные господа функциональщики итт, могут объяснить человеку с процедурщиной головного мозга, чем паттерн матчинг принципиально отличается от условных конструкций switch\case if\else?

>>1099886
Ничем не отличается. И именно поэтому его перенимают нормальные языке программирования.

>>1099886
Во-первых, он тупо удобнее.

Во-вторых, он по-настоящему статически типизирован. Если ты матчишь что-то, то внутрь конкретного clause'а передается тип сматченного объекта. То есть если ты сматчил, например, список или non-null, то компилятор знает, что в этой ветви кода вот это значение имеет соответствующий тип (непустой список или не нулл объект).

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

В-четвертых - и это следует из предыдущего - он декларативен. Декларативные описания (что) короче и понятнее императивных (как). Всегда следует пытаться использовать декларативные описания, если это возможно.

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

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

Итого: это обобщение свитчей и ифов с эффективной реализацией, которое удобнее использовать на практике.

Когда постигнешь дзен, приходи за второй частью поста (концептуальной) - о том, чем паттерн матчинг плох.

>>1099888
Короче говоря, вся его польза только для тех языков, где компилятор заранее знает всё об окружении (статическая типизация, например). Для динамики разницы никакой, верно?

>>1099892
Нет, неверно.

>>1099888

>Во-вторых, он по-настоящему статически типизирован
А если язык динамический?

>Там, где с обычными условиями тебе придется писать лапшу из тонны вложенных ифов
whatever_check(x)

>>1099893
Очень конструктивно, если учесть, что половина аргументов были основаны на том, что не походит для динамических языков.

>>1099895
>А если язык динамический?
То остаются все пункты, кроме второго (на самом деле, и второй тоже остается, потому что тайпхинты проще генерировать).

> whatever_check(x)
Либо разговаривай полными предложениями на русском языке, либо ожидай, что тебя рано или поздно пошлю нахуй.

>>1099896
> половина аргументов были основаны на том, что не походит для динамических языков.
Перечитай пост еще раз. Если что-то непонятно - можешь спрашивать. Хотя вообще, желательно прочитать хотя бы ` https://en.wikipedia.org/wiki/Pattern_matching `, прежде чем спрашивать.

пошлют
-- важный быстрофикс*

*пошлют
-- важный быстрофикс
абу пидор

>>1099897
Какой же ты ЧСВшный обмудок, хоспаде.

>>1099900
Обсуждать меня или других анонов можно в /soc, здесь же обсуждают программирование. Если у тебя больше нет вопросов, то скажи спасибо и покинь тред.

>>1099892
>Для динамики разницы никакой, верно?
Если бы в динамическом Эрланге не было бы паттерн-матчинга, то можно было бы повеситься, описывая всякие протоколы педерачи данных.

>>1099886
Всем.

>>1099895
>А если язык динамический?
Не бывает.

>>1099260 (OP)
>Паттерны функционального программирования обсуждать тут
А хуле там обсуждать-то? Все что можно - смоделировал с помощью ADTs, заебенил нужные трансформации чистыми функциями, получение данных из внешних источников присобачил сбоку. Просто, как палка.
Скажи, а что ты за задачу решаешь с деревьями компонентов? Вротенд пишешь небось?

>>1100022
>заебенил нужные трансформации чистыми функциями
В чем выражается "чистота" функции, каков критерий?
Если функция в процессе своего выполнения задействует функцию для промежуточных преобразований из внешнего окружения - он уже не является чистой?
За истину примем, что выполнение этих функций не приводит к изменению данных.

>>1100024
>За истину примем
Не примем.

>>1100033
>Не примем.
Что так?
Есть противоречия?

>>1100022
>Просто, как палка.
Манька из башни из слоновой кости капчует?

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

>>1100024
>В чем выражается "чистота" функции, каков критерий?
Иди нахуй википедию читать.

>>1100042
>Иди нахуй википедию читать.
Читал, и не только википедию. В одних случаях авторы пишут, что критерию чистоты удовлетворяет тот факт, что функция не изменяет данные, в другом, что не изменяет данные И не использует окружение.
Или понятие чистоты функции не является языконезависимым?
Я ж не ради срача, есличо.

>>1100047
Он тебе не сможет объяснить. Так же как не смогли те, кого ты читал. У всех функциональщиков собственное представление тех или иных вещей, которое они даже не способны сформулировать. Это как фингербокс.

>>1100047
>Я ж не ради срача
Ну тогда ладно.

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

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

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

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

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

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

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

>>1100068
Говна поешь, собака.

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

>>1100187
Пожалуйста.

Как совмещать ооп-дизайн с фп-дизайном? В той же скале, например.

>>1099260 (OP)

>>1102817
Никак. На это способны только настоящие джедаи высшего совета, типа Одерского и ещё пары человек. Остальные пытаясь совмещать ООП и ФП закономерно нахлёбываются урины.

>>1099886
Тем , что это совершенно разные вещи.

>>1104831
Ну я же не про дизайн языка говорил, а про использование.

Ок, вот смотри. У меня есть неймспесы, а в неймспейсе функция, которая возвращает главную структуру для этого неймспейса. Ну, в ооп это был бы конструктор. То есть у меня модуль My.Stuff.Foo, и в нем условно объявлена data Foo, и функция foo opts = Foo init...with...opts, нутыпонел. И в итоге получается как-то уебищно - везде это foo: Foo.Foo, Foo.foo, etc.

Как сделать красиво?

>>1104840
Я тоже говорю про использование.
И я нихуя не понял в твоём примере. Если ты пишешь в ООП стиле, просто используй конструктор, или объект-компаньон, а если в ФП , то я вообще не понял в чём у тебя проблема.

>>1104844
В том, что некрасиво, я же написал. Прочитай внимательно, я же подробно все описал.

Алсо, где я возьму в х-ле конструктор, ты чего.

>>1102817
Посмотри CLOS

>>1099260 (OP)
Ебашь, они нихуя не сделают!

>>1099873
>Один из тех долбоебов-байтоебов, программы которых имеют свойство крошиться и течь после серии продожительной разработки и отладки?

>>1099873
1.
log(2) = 1
log(2 000 000 000) ~= 30.89
ПИЗДЕЦ ТРАГЕДИЯ
2. Думаешь константы (в смысле реальное время выполнение операций) в реальном коде будут меньше или больше порядка разницы в п.1?

>>1104906
Да не, речь вообще про другое.

>>1105068
Двачую вот этого.

>>1099557
Так вот все эти алгебраические и теоретикокатегорные сущности типа функторов, монад, групп, моноидов, сетоидов и т.д. и т.п. - те же паттерны, только строго формализованные (чем и отличаются в выгодную сторону от "ООП-паттернов")

>>1099367
Полную хуйню списданул

>>1105689
>те же паттерны, только строго формализованные
>та же вода, только сухая
>те же нигеры, только белые

>>1105691
Сам дурак.

>>1105689
Ну давай доказывай уже начинай.

>>1102817
Используешь классы как иммутабельные типы данных в других фп языках и одновременно как модули из ML