Size: a a a

2019 December 16

SG

Serge S. Gulin in fprog_spb
Я так понял, что нельзя найти "паттерны". Можно только все вытаскивать в функции, использовать карирование по-умолчанию везде, а далее идти к point-free.
источник

YS

Yuriy Syrovetskiy in fprog_spb
общепринятой классификации паттернов ФП нет
источник

YS

Yuriy Syrovetskiy in fprog_spb
есть, например, Handle/Service pattern
источник

SG

Serge S. Gulin in fprog_spb
Парадигма ФП обладает особенностью в том, какой язык бы не был, все в итоге сводится к лямбда-счислению с оговорками, а оно везде выглядит одинаково.
источник

YS

Yuriy Syrovetskiy in fprog_spb
Serge S. Gulin
Я так понял, что нельзя найти "паттерны". Можно только все вытаскивать в функции, использовать карирование по-умолчанию везде, а далее идти к point-free.
некоторые паттерны можно найти
источник

YS

Yuriy Syrovetskiy in fprog_spb
Serge S. Gulin
Парадигма ФП обладает особенностью в том, какой язык бы не был, все в итоге сводится к лямбда-счислению с оговорками, а оно везде выглядит одинаково.
нет, не всё
источник

SG

Serge S. Gulin in fprog_spb
Ок ок, тут негр с руками
источник

SG

Serge S. Gulin in fprog_spb
Я просто имхую
источник

RM

Roman Makarov in fprog_spb
Как минимум есть набор ограничений, и когда пишешь на таких языках как python/ts тебе нужно за ними следить явно. И все равно сам факт того, что ты пишешь на функциональном языке не сделает код читаемым и масштабируемым.
источник

YS

Yuriy Syrovetskiy in fprog_spb
как известно, паттерны — это багрепоты к дизайну языку. некоторые из этих багов исправлены в ФП, но не во всех языках и по-разному
источник

RM

Roman Makarov in fprog_spb
спорно)
источник

YS

Yuriy Syrovetskiy in fprog_spb
Yuriy Syrovetskiy
как известно, паттерны — это багрепоты к дизайну языку. некоторые из этих багов исправлены в ФП, но не во всех языках и по-разному
идеальных языков всё равно нет, и ограничения в дизайне у всех есть, так что и паттерны находятся
источник

SG

Serge S. Gulin in fprog_spb
У меня на практике многое сводится к следующему:
1. Если вычисление можно выразить без контекста, то карирование, ramda, ski и point-free.
2. Если Контекст может быть выражен через монады, то:
2.1. Если монады часть языковых конструкций, то отдать преимущество языку (например async/await)
2.2. Если монады не часть языковых конструкций, то брать их из fp-ts
3. Случаи несуществования преимущественно выражать через монады Option/Either.
4. Исключения использовать только в случае гарантированно фатальных происшествий.
источник

SG

Serge S. Gulin in fprog_spb
Ну и да, любое FRP выражать через RxJS
источник

PK

Pavel Khritonenko in fprog_spb
> Исключения использовать только в случае гарантированно фатальных происшествий.

А потом либо знание об ошибках тащить по стэку, либо все проверки. Есть опыт написания и через исключения, и через either. Оба подхода имеют свои минусы
источник

АГ

Александр Гранин in fprog_spb
Roman Makarov
Мотивация такая -  сейчас разрабатываю на ts/python, где существует явный тренд на идемпотентый stateless бекенд, что интуитивно пересекается с идеями фп.  Поэтому возник интерес покопать в эту сторону. Из традиционных фп языков знаком с clojure. Вот интересуюсь, может подскажете годную литературу, где высокоуровнево описаны основные паттерны фп (Типа чистой архитектуры боба, но по ФП). Или просто статейки почитать и пробовать применять? Может у вас был опыт постепенного внедрения фп парадигм в проекте? Типа того, что недавно @gulinserge описывал.
У меня есть два showcase на Haskell:

https://github.com/graninas/servantEcho

https://github.com/graninas/Hydra

Там web сервер, бэкенд

(Ну и книга про это, и статьи, идоклады)
источник

АГ

Александр Гранин in fprog_spb
Там, конечно, сплошные монады
источник

АГ

Александр Гранин in fprog_spb
(Проект servantEcho делали мои ребята)
источник

RM

Roman Makarov in fprog_spb
Ок, спасибо, гляну.
источник

АГ

Александр Гранин in fprog_spb
Roman Makarov
Ок, спасибо, гляну.
Напишите, какие вам функции нужны в бэкендах, и я пришлю конкретные ссылки на код
источник