Какой смысл в лямбдах, если надо для каждой велосипедить интерфейс? :)
О том речь и шла — в джаве checked exceptions реализованы крайне неудобно. Потому не взлетели. А если сделать так, чтобы взлетели, то оно будет как монада :)
> Тем не менее, если конкретно вам она нужна — возможность ее использовать есть.
Я могу написать ф-ю, которая принимает лямбду с заданными checked exceptions? Нет.
Проблема у checked exceptions не с тем, что они, с-но, checked exceptions, а с тем, что их хреново реализовали в джаве. Можно реализовать по-человечески — но штука в том, что в этом случае оно будет только названием отличаться от встроенной в язык монады Either. Точнее — это _и будет_ монада Either!
Да, конкретные монады (из классических, то есть у которых есть какая-то общепринятая семантика, как у той же Maybe), наверное, можно считать паттернами.
Однако, почему тогда не считать паттерном в ООП какой-то _конкретный_ класс? Так ведь не поступают, по каким-то причинам.
> ни одна функция из определенных в обсуждаемом тексте в примерах на F# не имеет явной сигнатуры!
Явной не имеет, но по факту сигнатура есть. Вы увидите ее, если наведете мышкой на ф-ю в ИДЕ, ну и компилятор вам в любом случае напомнит, если вы вдруг не обработаете ошибку.
Тем, что этим занимается только некоторый класс монад, но далеко не все. Условно говоря, у нас есть несколько широких классов монад: монады контейнерные (типа List), монады, протаскивающие контекст (State), монады, управляющие потоком управления (вроде Maybe) ну и эзотерические, имя им легион (Cont, например)
> Монада — это тип данных, то есть нечто существующее в рантайме. Чем же в таком случае отличаются монады и костыли рантайма?
Монады — это то, как мы используем некий набор функций. Способ. Мы можем этот способ инкапсулировать в тип данных, но это совсем не обязательно. И этот способ мы можем реализовать сами на основе базовых объектов, функций, и поправить его как угодно. Никакой поддержки со стороны компилятора или рантайма при этом не требуется. Исключения, в противовес, это особый объект, который дан нам разработчиком языка, вещь в себе.
> По поводу типизации — вон в Java есть checked exceptions.
Именно так. У _конкретной_ монады назначение есть. У монады в общем (какой-то, неизвестно какой) — назначения нет. Это слишком общий объект, сказать про что-то «оно монада» — практически, ничего полезного не сказать. Что с этим чем-то будут делать — вывести уж точно нельзя.
> У объекта первого класса
Монада как бы не особо объект первого класса да и вообще не программный объект. Ее программным объектом, конечно, можно сделать (запаковать нужные ф-и в класс, например), но этого не требуется. Слово «конструкция» на мой взгляд наиболее точно отражает положение вещей. Есть некая конструкция (которая может быть реализована как угодно), и если она обладает определенными особенностями, то это — монада.
> По вашему, паттерны ФП внезапно перестают быть паттернами в какой-то момент универсальности?
По моему (и это, повторюсь, не только по моему, это общепринятый взгляд на вещи) сущность перестает быть паттерном, если у нее нет конкретного, четко формулируемого назначения.
> А паттерн «Интерфейс» внезапно перестает быть паттерном?
Там же у вас в первых же строчках на вики написано конкретное назначение паттерна — обеспечить программисту простой или более программно-специфический способ доступа к другим классам. Сможете сходным образом описать назначение монад?
> И все просто потому вы хотите
Я ничего не хочу. Мне лично без разницы, как и что вы будете называть. Кажется, я достаточно ясно раскрыл свою точку зрения, а какими конкретно словами она выражается — для меня совершенно несущественно. Если фп-конструкции удовлетворяют вашему пониманию термина «паттерн» — ну так пусть удовлетворяют, я не против. Сущность объекта не зависит от того, как этот объект называют, пусть хоть «тирьямпампация» :)
Дык монады это не сущность, это просто то, как мы называем определенную конструкцию. А так там обычные ф-и — к которым монады полностью сводятся. И именно в том, что у монад под капотом обычные функции, которые ведут себя как обычные функции — и есть преимущество «монадического» решения. Не требуются специальные костыли рантайма, информация о наличии ошибок — содержится в типе, при наличии статической типизации — компилятор гарантирует что ошибка будет обработана, ну и поскольку это все — first-class citizen, то оно может быть допилено под конкретные нужды. С исключениями такое уже не прокатит.
Давайте определимся с терминологией, чтобы друг друга понимать. Я под «паттерном» понимаю нечто, что, в частности, имеет четкое назначение. Это соответствует общепринятому смыслу, вкладываемому в термин «паттерн». В этом смысле паттернов в ФП нету, потому как все конструкции слишком универсальны. Если же под «паттерном» подразумеваются какие-то «классические» приемы, которые туда-сюда ходят и применяется в том или ином контексте — то такое, безусловно, есть.
Ну да, исключения по control-flow изоморфны maybe/either/etc или что там еще. Однако, вариант с монадами лучше исключений тем, что, ну, там нет исключений :)
Плюс — всегда можно упороться трансформерами и засовывать туда на call site дополнительную логику, не меняя сам код. Но я лично не ярый сторонник подобного.
> то это значит что она настолько ненужна в практической разработке, что под нее даже не пишут никакую теорию
Под ФП есть огромное количество теории. Просто паттернов в этой теории нету. Там есть монадные трансформеры, стрелки, а также зигохистоморфные препроморфизмы с пределами и копределами. А паттернов — вот нет, не завезли :)
И, да, эту теорию можно применять на практике. Например, благодаря этой теории я знаю, что могу использовать синтаксис генераторов в js с любой монадой, в которой fmap применяет свой аргумент не более раза :)
> Если бы автор привел пример, где каждая ветка, которая может пойти не так выдавала бы свое сообщение об ошибке
Так эти ветки внутри функций за |>
Функции выдают ошибку. В коде с монадами нам не надо при этом создавать ветки в вызывающем коде, а в коде с ООП — нужно было бы.
Там ведь код на картинке будет тот же самый. Просто в другой монаде (она там, вообще говоря, не указана, просто мы из контекста знаем, что автор говорил о Maybe).
> Позвольте. Редюсеры должны быть чистыми функциями, состояние не должно изменяться, вместо этого мы возвращаем новое состояние. Кажется это принципы функционального программирования.
Это были бы принципы функционального программирования, если бы на этом подходе строился поток управления в целом. Но 90% логики остается в грязных функциях с сайд-эффектами, а в редьюсерах — мелочь. Редакс ведь не про редьюсеры, редьюсеры можно исопльзовать и без редакса. Он про стор (который работает грязно) и про action creators и их middleware (которые работают грязно). В редаксе используются чистые функции? Используются, с этим не поспоришь. Но они в той же мере абсолютно везде используются. Важно — как используются. Если подход основан на использовании чистых ф-й — можно говорить об ФП. Если подход основан на использовании грязных функций (как в случае редакса) и там где-то применяются чистые функции — то тут об ФП говорить рановато.
> Если какой-то подход имеет строго выраженную идею, структуру и применяется для достижения конкретных целей – это паттерн.
Я и говорю, в этом понимании в ФП нету паттернов.
> Каррирование, Промисы, Коллбеки – это все паттерны.
Нет, каррирование и коллбеки — не паттерны. Так как у них нет назначения. То самое упомянутое вами «применяется для достижения конкретных целей». Не существует никаких конкретных целей для применения каррирования в общем. Так же как нету их для применения, например, монад в общем. Правильнее называть это каким-то другим словам, например — «концепция».
Речь об объективных, измеряемых факторах, а не о том, что кому-то представляется.
В этом случае и проблем с отсутствием сигнатуры не будет, очевидно :)
Да это просто пример. У checked exceptions много разных проблем из-за врожденной кривизны.
Нет, это не по моей логике. По чьей-то чужой, возможно.
О том речь и шла — в джаве checked exceptions реализованы крайне неудобно. Потому не взлетели. А если сделать так, чтобы взлетели, то оно будет как монада :)
Я могу написать ф-ю, которая принимает лямбду с заданными checked exceptions? Нет.
Проблема у checked exceptions не с тем, что они, с-но, checked exceptions, а с тем, что их хреново реализовали в джаве. Можно реализовать по-человечески — но штука в том, что в этом случае оно будет только названием отличаться от встроенной в язык монады Either. Точнее — это _и будет_ монада Either!
Да, конкретные монады (из классических, то есть у которых есть какая-то общепринятая семантика, как у той же Maybe), наверное, можно считать паттернами.
Однако, почему тогда не считать паттерном в ООП какой-то _конкретный_ класс? Так ведь не поступают, по каким-то причинам.
Явной не имеет, но по факту сигнатура есть. Вы увидите ее, если наведете мышкой на ф-ю в ИДЕ, ну и компилятор вам в любом случае напомнит, если вы вдруг не обработаете ошибку.
А явная сигнатура кому нужна-то, по факту?
Монады — это то, как мы используем некий набор функций. Способ. Мы можем этот способ инкапсулировать в тип данных, но это совсем не обязательно. И этот способ мы можем реализовать сами на основе базовых объектов, функций, и поправить его как угодно. Никакой поддержки со стороны компилятора или рантайма при этом не требуется. Исключения, в противовес, это особый объект, который дан нам разработчиком языка, вещь в себе.
> По поводу типизации — вон в Java есть checked exceptions.
И они по определенным причинам не взлетели.
Именно так. У _конкретной_ монады назначение есть. У монады в общем (какой-то, неизвестно какой) — назначения нет. Это слишком общий объект, сказать про что-то «оно монада» — практически, ничего полезного не сказать. Что с этим чем-то будут делать — вывести уж точно нельзя.
> У объекта первого класса
Монада как бы не особо объект первого класса да и вообще не программный объект. Ее программным объектом, конечно, можно сделать (запаковать нужные ф-и в класс, например), но этого не требуется. Слово «конструкция» на мой взгляд наиболее точно отражает положение вещей. Есть некая конструкция (которая может быть реализована как угодно), и если она обладает определенными особенностями, то это — монада.
По моему (и это, повторюсь, не только по моему, это общепринятый взгляд на вещи) сущность перестает быть паттерном, если у нее нет конкретного, четко формулируемого назначения.
> А паттерн «Интерфейс» внезапно перестает быть паттерном?
Там же у вас в первых же строчках на вики написано конкретное назначение паттерна — обеспечить программисту простой или более программно-специфический способ доступа к другим классам. Сможете сходным образом описать назначение монад?
> И все просто потому вы хотите
Я ничего не хочу. Мне лично без разницы, как и что вы будете называть. Кажется, я достаточно ясно раскрыл свою точку зрения, а какими конкретно словами она выражается — для меня совершенно несущественно. Если фп-конструкции удовлетворяют вашему пониманию термина «паттерн» — ну так пусть удовлетворяют, я не против. Сущность объекта не зависит от того, как этот объект называют, пусть хоть «тирьямпампация» :)
Давайте определимся с терминологией, чтобы друг друга понимать. Я под «паттерном» понимаю нечто, что, в частности, имеет четкое назначение. Это соответствует общепринятому смыслу, вкладываемому в термин «паттерн». В этом смысле паттернов в ФП нету, потому как все конструкции слишком универсальны. Если же под «паттерном» подразумеваются какие-то «классические» приемы, которые туда-сюда ходят и применяется в том или ином контексте — то такое, безусловно, есть.
Плюс — всегда можно упороться трансформерами и засовывать туда на call site дополнительную логику, не меняя сам код. Но я лично не ярый сторонник подобного.
Под ФП есть огромное количество теории. Просто паттернов в этой теории нету. Там есть монадные трансформеры, стрелки, а также зигохистоморфные препроморфизмы с пределами и копределами. А паттернов — вот нет, не завезли :)
И, да, эту теорию можно применять на практике. Например, благодаря этой теории я знаю, что могу использовать синтаксис генераторов в js с любой монадой, в которой fmap применяет свой аргумент не более раза :)
Так эти ветки внутри функций за |>
Функции выдают ошибку. В коде с монадами нам не надо при этом создавать ветки в вызывающем коде, а в коде с ООП — нужно было бы.
Там ведь код на картинке будет тот же самый. Просто в другой монаде (она там, вообще говоря, не указана, просто мы из контекста знаем, что автор говорил о Maybe).
Это были бы принципы функционального программирования, если бы на этом подходе строился поток управления в целом. Но 90% логики остается в грязных функциях с сайд-эффектами, а в редьюсерах — мелочь. Редакс ведь не про редьюсеры, редьюсеры можно исопльзовать и без редакса. Он про стор (который работает грязно) и про action creators и их middleware (которые работают грязно). В редаксе используются чистые функции? Используются, с этим не поспоришь. Но они в той же мере абсолютно везде используются. Важно — как используются. Если подход основан на использовании чистых ф-й — можно говорить об ФП. Если подход основан на использовании грязных функций (как в случае редакса) и там где-то применяются чистые функции — то тут об ФП говорить рановато.
Я и говорю, в этом понимании в ФП нету паттернов.
> Каррирование, Промисы, Коллбеки – это все паттерны.
Нет, каррирование и коллбеки — не паттерны. Так как у них нет назначения. То самое упомянутое вами «применяется для достижения конкретных целей». Не существует никаких конкретных целей для применения каррирования в общем. Так же как нету их для применения, например, монад в общем. Правильнее называть это каким-то другим словам, например — «концепция».